Immutable backups: who can still delete them?
"Immutable" is used for very different things: snapshots, append-only repositories, object lock, offline disks. They don't protect against the same people. The useful question isn't whether a backup is called immutable, but who can still delete it, and whether that credential is reachable from the server it protects.
The one question that matters
Ransomware and intruders go after backups on purpose. CISA notes that many ransomware variants look for reachable backups and delete or encrypt them. So for every copy, ask:
The options compared
| Method | Who can still delete | Watch out for |
|---|---|---|
| Plain backup target SFTP, NFS, a NAS share | Anyone with the backup credentials, which live on the server being backed up | This is the copy ransomware deletes first. Not immutable at all. |
| Snapshots filesystem, NAS or provider snapshots | Anyone with admin rights on the storage | Often marketed as immutable, but they're usually a restore convenience. If the storage admin account is the same one your servers use, or is reachable from them, an attacker can remove the snapshots too. |
restic rest-server, --append-only | Not the backup client. Anyone with full access to the repository can, from another machine. | Retention must run elsewhere, and restic recommends time-based forget --keep-within: count-based policies can be gamed with fake snapshots. Details. |
| borg, append-only mode | Not immediately. A client's deletes are only marked, but the next normal-mode write by anyone makes them permanent. | Check the repository state before any admin-side prune or compaction. Details. |
| S3 Object Lock, governance mode | Users who've been given special permission to bypass it | Protects against most users, but an admin who holds or can grant that permission can still delete or shorten retention. |
| S3 Object Lock, compliance mode | Nobody, including the account's root user, until retention expires | That includes you: mistakes and oversized retention can't be undone. AWS documents that the only way out early is deleting the whole AWS account. |
| Offline copies rotated disks, tape | Only someone with physical access | Safe from the network, but only as fresh as the last rotation, and only as reliable as the person doing it. |
Combining them
No single method covers everything, so most solid setups combine two:
- A fast copy you can restore from quickly, which doesn't need to be immutable: local disk or NAS.
- An offsite copy the protected server can't delete: append-only or object lock, with retention controlled from somewhere the server can't reach.
- Optionally, an offline copy for the case where every online credential is lost.
Whatever you combine, keep the delete-capable credential off the servers being backed up, and watch the immutable copy as closely as the others. An immutable copy that silently stopped receiving backups three weeks ago only protects three-week-old data.
Checklist
- For each copy, write down which account can delete it.
- Confirm none of those accounts' credentials are stored on the servers being backed up.
- Check that retention for the immutable copy can't be shortened from those servers either.
- If you use append-only with restic or borg, make sure pruning runs only from a separate machine, and review before it runs.
- Restore something real from the immutable copy at least once a quarter.
- Alert when the immutable copy stops receiving new backups, not only when a job fails.
How the Servatum Vault fits
The Vault is an append-only restic repository run for you: your server's credentials can add snapshots but not remove them, retention is time-based and runs on our side, and changes that shorten retention take effect after a delay. It isn't live yet; the Vault docs describe how it will work.
Join the waitlist