Object Lock on a backup bucket produces a clean answer during an audit. The data cannot be changed or removed until the retention date passes, and no console button reverses that. The answer is accurate, and it is narrower than most teams read it to be. Immutability is a property of stored objects. It is not a property of the system that wrote them, the index that describes them, or the credentials that reach them.
The gap matters because an attacker who cannot delete a backup can still make it useless. Restoring from object storage is not a single operation. It depends on a catalog that maps machines and restore points to objects, on software that can read the format, on credentials, and on somewhere to put the restored workload. Retention protects one link in that chain.
The second gap is quieter. Immutability applies to what was written. It says nothing about what was skipped, what failed the night before, or what was dropped from a job three months ago and never noticed since. A locked object is evidence of storage, not evidence of coverage.
When a backup application writes to a bucket with Object Lock in place, each object version receives a retain-until date. Until that date passes, the storage layer refuses overwrite and delete requests for that version, whatever credentials and administrative rights they carry. The refusal happens below the application, so a compromised backup server issuing a legitimate delete call gets the same answer as anyone else.
That guarantee is version-scoped and object-scoped. It protects the specific bytes in the version that was written. It does not extend to the bucket's future behavior, to other buckets, or to metadata the application keeps elsewhere. The boundary between the lock and the system around it is treated in what Object Lock actually guarantees.
Retention also has an end. Every locked version eventually becomes deletable, and the distance between the oldest surviving protected copy and the moment an intrusion began is a recovery constraint rather than a storage one. A thirty day retention period means an intrusion found on day thirty-five has no protected copy from before it started.
Most backup products keep a catalog: a database recording which machines, restore points, backup chains and encryption keys correspond to which stored objects. That database normally lives on the backup server or an adjacent SQL instance. It is not in the immutable bucket, and nothing in the bucket's retention policy covers it.
Without the catalog the objects are still present and still readable, in the sense that they can be listed and downloaded. Turning them back into usable restore points requires the vendor's import procedure, an installation of the same product version, and hours or days rather than minutes. Teams that have never run it find out how long it takes during the incident.
The test is narrow and cheap. Stand up a fresh installation of the backup software with no catalog, point it at the bucket, run the import, and record the elapsed time. That number is the real floor on recovery when the backup server is gone.
An attacker holding the backup server inherits its access. Retention stops deletion, but it does not stop reading. Backup data contains directory databases, file shares, mailboxes and application data, so an environment with flawless immutability can still suffer complete data disclosure through the backup path alone. Immutability is an integrity control and not a confidentiality one.
Job configuration is equally exposed. Schedules can be disabled, retention on new jobs shortened, inclusion lists trimmed, and a second job pointed at an unlocked bucket. None of that touches an existing locked object, and all of it degrades the next thirty days of coverage. The damage appears later, as a gap rather than as an alert.
The restore path itself is often the binding constraint. Restoring needs compute, capacity, network paths, addressing, name resolution and authentication. When all of those depend on the estate that was encrypted, protected copies have nowhere to land. That is why air gap and immutability behave as complementary controls rather than interchangeable ones.
| What an attacker can still do | Why immutability does not stop it | What to check |
|---|---|---|
| Destroy or encrypt the backup catalog | The catalog sits outside the locked bucket | A timed, catalog-free import into a clean installation |
| Read and exfiltrate backup content | Retention blocks writes and deletes, not reads | Which identities can list and get objects |
| Disable jobs or shorten retention | Existing versions keep their date; new writes follow new settings | Job change history and alerts on retention changes |
| Point a job at a bucket without Object Lock | Lock is a per-bucket property, not an account-wide guarantee | A bucket inventory showing lock mode and default retention |
| Wait out the retention window | Every locked version becomes deletable once its date passes | Oldest protected copy against realistic detection time |
| Rely on systems never backed up | The lock applies only to objects that were written | Protected inventory reconciled against the live machine list |
A retention policy is silent about scope. If a virtual machine was created after the last review of a job's inclusion list, no amount of locking makes a copy of it exist. The same holds for a database the agent does not enumerate and a file share on a host nobody added.
Failed jobs produce the same effect over shorter periods. A job that has errored every night for two weeks leaves a locked, intact, two week old copy behind it, and that copy looks entirely healthy in a bucket listing.
The reconciliation that catches this is dull and quick. Take the authoritative list of systems from the virtualization platform, the directory and the asset register, and compare it by name with the list of protected systems. The useful output is the set difference, not the total count.
ARTESCA is object storage software used as a backup target, running on infrastructure the customer operates, at capacities from roughly 50 TB to 8.5 PB. It presents an S3-compatible API and supports S3 Object Lock, so a backup application writing with retention receives the storage-side refusal described above, enforced independently of the host that issued the request.
Because it is deployed on the customer's own hardware, the boundaries around it are the customer's decisions: which network segment it occupies, which identity system its administrative access uses, who holds the storage-side credentials, and where encryption keys are kept. Those decisions determine how much of the surrounding chain is protected.
The catalog is the same story. ARTESCA holds the backup data, while the backup application keeps its own metadata according to its own design. A recovery plan built on immutable object storage still needs a tested route from a bucket full of objects back to a running workload.
Three checks cover most of the gap. The first is a catalog-free restore once or twice a year: a clean installation, an import from the bucket, one machine restored end to end, elapsed time written down. The second is a monthly reconciliation of protected systems against the real inventory. The third is a quarterly read of bucket configuration, listing every bucket the backup software can reach with its lock mode and default retention.
Record the retention floor next to the detection assumption. If the oldest protected copy is thirty days old and nothing would surface a quiet intrusion inside thirty days, the protected window is shorter than the exposure window. Deciding which copy deserves trust once an intrusion date is known is covered in choosing a clean recovery point.
Finally, write down who holds the credentials that can create buckets, change lock settings and change job retention, and confirm that this list is shorter than the list of people who can run a restore. Restoring is routine work that several people should manage under pressure. Changing the terms under which data is protected is not.