Ransomware-proof backups: 3-2-1-1-0, immutability, and a restore you've actually tested

Every company we take on believes it has backups. Most do. What most do not have is backups that survive the specific way ransomware works — because modern attackers do not just encrypt your production data, they hunt down and delete or encrypt your backups first, precisely so you have to pay. A backup an attacker can reach is not a backup; it is a second copy waiting to be taken hostage. Here is the design that actually holds, and the two things — immutability and a tested restore — that separate a real recovery plan from a false sense of safety.

Why ordinary backups fail against ransomware

The failure is not that backups do not exist. It is that they are reachable. Ransomware, once it has domain or admin credentials, does reconnaissance: it finds the backup server, the NAS with the nightly copies, the cloud bucket with the same login as everything else, and it destroys them before triggering encryption. If your backups live on the same domain, behind the same credentials, on always-online storage, they share the fate of production. Recoverability, not backup, is the thing to design for.

The rule: 3-2-1-1-0

The old 3-2-1 rule grew two digits for the ransomware era:

• •3 copies of your data,
• •on 2 different media/storage types,
• •with 1 copy offsite,
• •1 copy offline or immutable (air-gapped or write-locked so nothing — not even an admin, not even the attacker — can alter or delete it within its retention),
• •and 0 errors, verified by an automated restore/integrity test.

The two new digits are the whole point. The 1 (immutable) is what an attacker cannot destroy. The 0 (verified) is what turns "we have backups" into "we have restored them."

Immutability, concretely

"Immutable" has to mean something the running system cannot override. The real options:

• •Object storage with a lock — S3 Object Lock (or the equivalent on other clouds and on MinIO on-prem) in compliance mode, so a copy cannot be deleted or changed until its retention expires, regardless of credentials.
• •A hardened backup repository — a Linux repository with single-use credentials and immutability flags (as Veeam's hardened repository does), separated from the domain, so a compromised Windows admin cannot reach it.
• •Purpose-built backup systems — Proxmox Backup Server, and the immutability features in Veeam and similar, which enforce retention locks and verification natively.
• •Offline/air-gapped — tape, or a rotated copy that is physically disconnected. Old-fashioned, and still the hardest thing for a remote attacker to touch.

The common thread: the immutable copy must not be deletable using the same credentials that run everything else. If one compromised admin account can wipe it, it is not immutable.

The restore is the backup

A backup you have never restored is a hope, not a plan — and untested restores fail at the worst moment, on the day you need them, for dull reasons: a missing encryption key, an incomplete application-consistent snapshot, a database that backed up mid-write. The discipline:

• •Test restores on a schedule, automatically where possible, to a scratch environment — not "we restored a file once in 2023."
• •Restore whole systems, not just files. Recovering a lost document is easy; standing an entire domain controller or database server back up under pressure is the real test.
• •Know your RTO and RPO, and prove them. How long recovery actually takes and how much data you actually lose are measured numbers from a rehearsal, not aspirations on a slide.

This is also where compliance and insurance now meet reality: NIS2 readiness and most cyber-insurance renewals explicitly ask for immutable backups and evidence of tested restores — because insurers learned the same lesson the hard way.

What we do

We design and run backup and recovery as part of managed infrastructure: 3-2-1-1-0 with a genuinely immutable copy the domain cannot reach, automated verification so the "0" is real, and scheduled full-system restore tests with measured RTO/RPO you can hand to an auditor or insurer. We would rather find the broken restore in a drill than have you find it during an incident. If you are not certain your current backups would survive an attacker — or that you could actually restore from them — that uncertainty is the finding, and a restore test is how we settle it.