Immutable restic backups: Object Lock, versioning, and the prune trade-off

Restic encrypts repository contents before they reach storage. That protects confidentiality, but it does not by itself prevent a credential from deleting encrypted objects. If an attacker compromises a backup client with delete access, encryption can remain perfectly intact while the repository disappears.

Immutability is a storage-side restriction on change or deletion for a defined period. Versioning is a recovery aid that retains earlier object versions after ordinary overwrite or delete operations. Append-only access lets a client add data while denying destructive operations. These controls overlap, but they are not synonyms and they fail differently.

Begin with the adversary. Accidental deletion by an operator, ransomware on one server, compromise of a cloud administrator, abuse of a lifecycle rule, and loss of an encryption key require different controls. A design that promises to be ransomware-proof without naming which credentials and administrators remain trusted is not specific enough to evaluate.

With S3 Versioning enabled, an ordinary delete adds a delete marker instead of immediately erasing prior versions. An overwrite creates a new current version and retains the previous one as noncurrent. This can make accidental deletion or a simple destructive client recoverable because the older object version still exists.

Versioning is not WORM storage. A principal with permission to delete a specific version can permanently remove it. Lifecycle rules can also expire noncurrent versions, and every retained version is billable as a complete object rather than as a delta. Delete markers and noncurrent versions therefore need monitoring as both a recovery resource and a cost driver.

For a restic repository, versioning may preserve objects that maintenance intended to remove. That can be valuable during an attack, but the repository's current namespace may still contain delete markers. Recovery can require object-version work outside restic before the repository looks normal again. Rehearse that process on a disposable repository instead of discovering it during an incident.

Amazon S3 Object Lock protects individual object versions from overwrite or permanent deletion for a retention period or legal hold. It requires Versioning. A bucket default can apply retention to new object versions, and the protected version remains locked until its retention date expires or its legal hold is removed under the applicable rules.

Governance and compliance modes deliberately trust different actors. Governance mode can be bypassed by a principal with the specific bypass permission, which is useful when controlled exceptions are required. Compliance mode is stricter: protected versions cannot be deleted during the retention period, including by the root user. A legal hold has no fixed expiry and remains until an authorized action removes it.

Object Lock has operational consequences beyond one checkbox. AWS states that Object Lock cannot be disabled on the bucket after it is enabled and that Versioning cannot then be suspended. It also does not protect access to encryption keys. A perfectly retained repository is still unrecoverable if its restic password or required storage-side encryption keys are lost.

Restic retention has two logical phases. Forget removes snapshot references selected by policy. Prune identifies repository data no longer referenced by retained snapshots, may repack partially used files, updates indexes, and deletes obsolete objects. Those destructive operations are how the repository returns storage space.

A lock that successfully prevents deletion also prevents prune from completing all intended cleanup while protected versions remain inside their retention window. Depending on the backend and the operation, a delete may fail or create a delete marker while the protected version continues to consume storage. Repacking can temporarily add new objects before old ones become removable. The practical result can be maintenance errors, accumulating noncurrent versions, and a bill that diverges from restic's logical repository size.

That is not an argument against Object Lock. It means the immutability window and the maintenance policy form one system. If the lock period is longer than the useful recovery history, storage cannot be reclaimed on the schedule suggested by the snapshot policy. If it is too short, a compromise may simply wait out the protection. Model data growth, provider lifecycle behavior, and the longest plausible detection delay together.

Restic's documentation describes an append-only repository as one where a backup client can read and add data but cannot delete or overwrite it. Its REST server supports such a mode, and other backends may need an intermediary or provider-specific control. The important architectural property is that routine backup credentials cannot erase earlier recovery data.

Forget and prune still need full read, write, and delete access. Restic therefore recommends running destructive maintenance from a separate, well-secured client. This changes the compromise boundary: taking over an ordinary workload host is no longer enough to prune the repository, while maintenance remains possible through a more tightly controlled path.

Append-only also changes safe retention reasoning. Restic warns that a compromised writer can add misleading snapshots with manipulated timestamps. A count-based policy executed later by a trusted maintenance client might then keep attacker-created snapshots and remove legitimate ones. The documentation recommends time-window retention for this model so suspicious extra snapshots remain visible within the protected window. The lesson is broader than one option: immutability must account for malicious writes, not only deletes.

There is no single immutable-restic layout that fits every threat model. Three patterns make the trade-offs easier to discuss.

• Versioned active repository: simple operationally and helpful against ordinary deletes, but authorized version deletion and aggressive lifecycle rules remain in scope.
• Append-only active repository with separate maintenance: routine clients cannot delete, while a trusted maintenance identity periodically applies retention and checks for suspicious snapshots.
• Ordinary active repository plus immutable secondary copy: the primary remains easy to prune, while a separately controlled copy preserves objects through a defined incident window.
• Object-locked active repository: strong provider-enforced retention, but prune behavior, delete markers, repacking, lifecycle processing, and storage growth require proof with the exact backend.

Choose an immutability period from detection and response, not from a round marketing number. Estimate how long ransomware, stolen credentials, silent corruption, or an operator mistake could remain unnoticed. Add the time needed to investigate without destroying evidence. The protected history must extend beyond that combined window.

Then test the economics. Measure new object growth, noncurrent-version growth, delete markers, and the temporary space used by maintenance. Confirm how the provider's lifecycle rules treat locked current and noncurrent versions. AWS documents that protected versions are not removed by lifecycle expiration while the lock remains active; lifecycle configuration still needs careful review once retention expires.

Keep repository retention and storage lifecycle policy conceptually separate. Restic knows which chunks are referenced by snapshots. A generic bucket lifecycle rule knows only object age and version state. Expiring repository objects solely because they are old can corrupt a repository whose newer snapshots still reference them.

Test three paths. First, restore normally from the current repository. Second, simulate an ordinary delete in a versioned test bucket and recover the previous object state. Third, rehearse recovery when current keys contain delete markers or when protected versions must be copied into a clean namespace. Record which identity and tools are required for each path.

Monitor the controls that make the promise true: Object Lock configuration, governance-bypass permissions, legal holds, version counts, lifecycle changes, failed maintenance, repository checks, last successful restore, and access to encryption material. Send those signals somewhere a compromised backup host cannot silence.

An immutable copy is valuable precisely because normal operators cannot quickly change it. That same property can slow legitimate cleanup and incident repair. Treat the inability to delete as a tested operational constraint, not merely a security feature enabled once in a storage console.