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

For most teams, the safest starting point is to keep ordinary backup credentials separate from destructive maintenance authority, retain an independently controlled recovery path, and test a restore. Add S3 Object Lock when you need provider-enforced, time-limited protection and can accept its effects on pruning and cost. S3 Versioning alone helps recover ordinary deletes, but it is not an immutability guarantee.

Restic encrypts data before it reaches storage. Encryption protects confidentiality; it does not stop a credential with sufficient permissions from deleting repository objects. Define whether you are defending against an accidental delete, compromise of a workload host, misuse of a maintenance credential, or compromise of a storage administrator. The answer determines which identity must be unable to delete earlier recovery data.

Record a recovery point objective (RPO)—the maximum tolerable data loss—and a recovery time objective (RTO)—the maximum tolerable time to restore service. A daily schedule might be chosen for a 24-hour RPO target, but a late or failed run can exceed it; only a timed restore drill gives evidence about RTO. Use the [RPO and RTO planning guide](/blog/rpo-vs-rto-small-teams-backup-frequency) to set these before choosing a retention window.

With S3 Versioning, an ordinary delete adds a delete marker and an overwrite creates a new version. Earlier versions may remain available, which can make a mistaken deletion recoverable. Restic still sees the current object namespace: a delete marker can make a required repository object appear absent even while an older version exists.

Versioning is not write-once-read-many (WORM) retention. An identity allowed to delete specific versions, or a lifecycle rule that expires noncurrent versions, can remove the recovery material. Noncurrent versions and delete markers also affect storage use. Restrict version-deletion and lifecycle authority separately from routine backup access, and inventory those rules before relying on version history.

After a destructive event, do not assume that removing one delete marker repairs a restic repository. Identify all affected keys and versions, reconstruct a coherent repository state in a separate prefix or bucket, then check and restore from that reconstruction. Practice on a disposable repository; restic cannot automatically select a historical, consistent set of S3 object versions.

Amazon S3 Object Lock protects individual object versions against permanent deletion or overwrite while their retention or legal hold applies. It requires Versioning. A bucket default can apply retention to newly written versions, but you must verify the effective protection on the repository objects you intend to preserve.

Governance mode can be bypassed by a principal with the required bypass permission. Compliance mode does not allow protected versions to be deleted or their retention shortened during the retention period, including by the AWS root user. A legal hold has no fixed end date and must be removed by an authorized action. Choose and restrict these authorities deliberately; neither mode protects a lost restic password.

AWS states that Object Lock cannot be disabled after it is enabled on a bucket and that Versioning cannot then be suspended. Treat bucket design as a durable decision. Protect the [recovery key and the people who can access it](/blog/backup-encryption-key-loss-recovery-ownership-plan), as well as any storage-side encryption keys required to read the objects.

Restic's forget removes snapshot references selected by a policy. prune then finds unreferenced repository data, can repack partially used files, updates repository metadata, and removes obsolete objects. See the [restic retention guide](/blog/restic-retention-policy) before changing either operation on a production repository.

A protected object version cannot be permanently deleted during its Object Lock retention period. Depending on the operation and storage behavior, maintenance can fail to complete or leave locked noncurrent versions behind after a delete marker is created. Repacking may add objects before old versions become removable. A successful forget, or a lower logical snapshot count, therefore does not establish that storage has been reclaimed.

Do not run destructive maintenance against a protected repository until you have tested its behavior with the exact backend, permissions, retention settings, and lifecycle rules. Alert on failed maintenance and growing noncurrent storage. Never use an age-only bucket lifecycle rule to delete current restic repository objects: an old object can still be referenced by a recent snapshot.

In restic's append-only model, a backup client can read and add repository data but cannot overwrite or delete earlier data. Restic's REST server supports an append-only mode; another storage backend needs a separately validated access design or intermediary. Do not assume that a generic object-storage policy alone implements every write behavior restic requires.

A separate, trusted maintenance identity still needs the access required for forget and prune. Keep it off ordinary workload hosts, give its use an approval and audit path, and inspect proposed retention changes before running them. A compromised writer can add misleading snapshots; restic warns that manipulated timestamps can undermine later count-based retention decisions. Prefer a reviewed time-window policy for this threat model.

Compare these layouts by who can delete recovery data, how cleanup works, and what the restore team must reconstruct. No layout eliminates the need to retain credentials and test recovery.

• **Lower operational cost:** a versioned active repository can help reverse ordinary deletes, provided version-deletion permissions and lifecycle rules are controlled. It does not withstand every privileged deletion.
• **Recommended starting design when supported and validated:** an append-only active repository with separate maintenance authority limits routine writers' deletion rights while leaving a deliberate cleanup path.
• **Stronger separation:** an ordinary active repository plus an independently controlled, protected secondary copy leaves the active repository easier to maintain. The copy procedure must preserve a usable repository state, not just a selection of recent objects.
• **Provider-enforced retention:** an Object-locked active repository protects retained versions for a set period, but requires the most careful proof of prune, version recovery, lifecycle behavior, and storage growth.