Immutable backups: how they really work

July 15, 2026 · 4 min read · SOVALYX Technologies

An immutable backup is a copy that nobody — not even an administrator — can modify or delete before the end of a retention period set at write time. With ransomware crews that go after backups before encrypting production, it is often the difference between restoring and paying.

A copy nobody can rewrite

The principle has an old name: WORM — Write Once, Read Many. You write once, read as often as you like, and never rewrite. Long confined to tape and optical media, it now lives in object storage through object lock: when the backup is written, a retention expiry date is attached to it. Until that date, any request to delete or overwrite the object is refused by the storage layer itself.

The nuance matters: the refusal does not come from a rule in the backup software, which an attacker holding the right credentials could disable, but from the underlying storage. If your backup tool, once compromised, can request deletion and obtain it, your copy is not immutable — it is merely protected by a policy.

Two lock modes that are not equivalent

Platforms generally offer two modes. In "governance" mode, certain privileged accounts can lift the lock: useful against manipulation errors, insufficient against an attacker who has stolen precisely those privileges. In "compliance" mode, nobody — customer or operator — can delete the object before expiry. For the copy meant to survive ransomware, compliance mode is the reference; governance mode remains acceptable for intermediate copies.

Air gap: cutting the path between production and backup

Immutability prevents rewriting; the air gap reduces exposure. The physical air gap is the oldest form: magnetic tapes taken out of the library and stored offline, off site. No network attack alters a tape in a safe. The logical air gap is its connected equivalent: the backup target lives in an isolated network zone, is reachable only during backup windows, and above all uses completely separate authentication from production — not the same directory, not the same accounts, not the same admin workstations.

That last point is the most commonly neglected: if the same domain administrator account can reach the hypervisor, the servers and the backup repository, the air gap is an illusion. Compromise the central directory and everything falls at once.

Retention: the 3-2-1-1-0 rule in practice

The classic 3-2-1 rule (three copies, two media, one off site) has grown: 3-2-1-1-0 adds one immutable or offline copy, and zero errors in restore testing. That extra, locked copy is the one that answers the ransomware scenario.

Retention length is a trade-off. Too short, and you are exposed to the dormant-attack scenario: patient intruders wait for the last clean backups to expire before triggering encryption. Too long, and storage costs balloon. The answer lies in tiering: frequent restore points kept immutable for a few weeks, weekly or monthly points kept longer, and a clear distinction between operational retention and regulatory archiving, which follows different rules. Sizing depends on your systems — our article on business backup strategy covers those choices in detail.

What it really changes against ransomware

Ransomware operators no longer encrypt production first: they hunt the backup infrastructure, delete snapshots, purge repositories and destroy catalogues — and only then trigger encryption, once the victim has no safety net left. An immutable, isolated copy removes that lever: even with a full compromise of the administration accounts, the copy remains restorable. That is what changes the negotiating position — you do not pay to recover what you can restore yourself. Our analysis of ransomware and backups goes deeper into these tactics.

But it only counts if restoration works, and works fast. The backup catalogue must itself be protected, restores tested regularly — single file, full machine, entire site — and restore time measured against your recovery objectives, as described in our disaster recovery plan guide. A clean copy that takes three weeks to restore does not save the business.

Checklist: is your backup truly immutable?

1. Is immutability enforced by the storage layer (object lock), not just by the backup software?
2. Is the lock in compliance mode for the last-resort copy — and who can lift it?
3. Are the backup infrastructure's credentials separate from the production directory?
4. Is there one off-site copy and one offline or logically isolated copy?
5. Does the retention period cover a dormant intrusion lasting several weeks?
6. Is the 3-2-1-1-0 rule met for critical systems?
7. Is the backup catalogue itself backed up and protected to the same level?
8. Has a full restore been tested recently, timed and documented — if not, schedule that test?

🧰 The companion tool: Would your backups survive a ransomware attack? — free · 2 minutes.

Reviewed and optimised by AI.