Immutable backups and the 3-2-1-1-0 rule for the ransomware era

Key takeaways

• Modern ransomware targets backups before encrypting production — so reachable, deletable backups are no backups at all.
• 3-2-1-1-0 adds one immutable/offline copy and zero restore errors verified by testing to the classic rule.
• Immutability only counts if the attacker can't reach the credentials or console that could disable it.

The old rule assumed backups were safe

The 3-2-1 rule — three copies, on two media types, one offsite — was written for a world where the threat was hardware failure and fire, not an adversary actively hunting your backups. Modern ransomware operators go after backup infrastructure first, precisely because destroying your ability to recover is what forces payment. A backup the attacker can reach, authenticate to, and delete is not a recovery capability; it's a false sense of one.

What the extra 1 and 0 add

The updated formulation is 3-2-1-1-0: keep the three copies on two media with one offsite, plus one copy that is immutable or air-gapped, and verify zero errors through regular restore testing. The extra '1' is the copy an attacker cannot alter even with domain admin. The '0' is the discipline that turns backups you hope work into backups you've proven work — because an untested backup is a liability discovered at the worst possible moment.

'Immutable' is only as strong as its control plane

Vendors market immutability aggressively, but the property is only real if the attacker can't disable it. If the same domain credentials that unlock every server can also log into the backup console and shorten the retention lock, the immutability is theater. True immutability means object-lock storage the production domain can't authenticate to, separate credentials, and a change process that can't be completed by a single compromised admin. Ask where the off-switch is and who can reach it — that's the real test.

Recovery order matters as much as the copies

Having a clean immutable copy is necessary but not sufficient. When you restore, you have to restore in the right order — identity and domain controllers before the applications that depend on them, and onto known-clean infrastructure so you're not restoring into an environment the attacker still controls. Document that sequence and test it; the copy is the ingredient, but the restore runbook is the recipe.