Backup repository patching is a task with two risks pulling in opposite directions. Leave the repository unpatched and it accumulates known vulnerabilities on the system that holds the last good copy of everything. Patch it carelessly and the maintenance work itself opens the access paths that immutability was meant to close. Most teams resolve the tension by patching rarely. A better answer is to patch on a schedule, through a path that is designed in advance.
This applies to any repository that enforces immutability, whether it is a hardened Linux server, an appliance or object storage software running on standard servers. The details differ, but the questions are the same.
An immutable repository is deliberately hard to reach. Remote login is disabled, administrative accounts are few, and the network exposes only the ports the backup software needs. Those same properties make routine updates inconvenient. There is also a reasonable fear of breaking something: a repository that fails to come back after a reboot interrupts every backup job that depends on it.
The result is a system that was secure on installation day and has drifted since. Firmware on the disk controller, the out-of-band management controller and the operating system kernel are the items most often left behind.
| Layer | Typical update path | Risk to manage during the update |
|---|---|---|
| Operating system and kernel | Local console, or a time-limited remote session | Remote access left enabled afterwards |
| Storage or repository software | Vendor update package or rolling upgrade | Running backup jobs interrupted mid-write |
| Disk and controller firmware | Vendor tooling, usually with a reboot | Reduced redundancy while a node is down |
| Management controller | Out-of-band network | Controller exposed to the production network |
| Backup software components on the repository | Pushed from the backup server | Elevated credentials stored after the push |
Patching itself rarely weakens immutability. What weakens it is the access opened to do the patching. A remote login service enabled for an afternoon and never switched off, a root password shared in a ticket, or a firewall rule widened for a vendor session and left in place are the usual ways a hardened system stops being hardened.
Three habits reduce that exposure. Access is opened for a stated window and closed by a second person, not by the engineer who did the work. Credentials used during the window are rotated when it ends. And the state of the repository is compared afterwards against a short written baseline: which services are listening, which accounts exist and which firewall rules apply. A backup security review for a small team gives a format for that baseline.
A patch window is not the time to alter retention or lock settings. If a procedure asks for immutability to be shortened or switched off so that an update can proceed, that is a sign the repository's protection depends on administrator goodwill. Where the lock is enforced in a mode that no administrator can lift, the question does not arise. Object Lock governance and compliance modes explains the difference and what each allows during maintenance.
It is also worth confirming that the system clock is untouched by the update. Retention periods are measured against the repository's time source, so a clock that jumps forward can release data early.
A single-server repository has to go offline to reboot, so its patch window competes with the backup window. Jobs need to be paused or allowed to finish, and the first run after the update should be watched to completion. Backup storage maintenance covers how to keep jobs running safely around planned work.
A repository built from several nodes can be updated one node at a time while the others continue to serve reads and writes. That removes the outage, though not the need for care: redundancy is reduced while a node is down, so a rolling update should wait for the system to report full health before moving to the next node.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires. An update to the software or the servers beneath it does not change the locks already applied to stored objects.
The servers still need operating system, firmware and management controller updates, as with any infrastructure. Because ARTESCA can span several servers, one can be taken out for maintenance without taking the repository offline. It grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
A workable routine fits on one page. It names a monthly or quarterly window, the layers covered in each, the access path used and who closes it, the health check that must pass before and after, and the restore test that follows a major update. Written down once and followed each time, it keeps the repository current without relying on anyone remembering to undo an exception.