Ransomware backup protection: the 3-2-1-1-0 rule

The old logic was simple: if you have copies, you can sleep soundly. Today that's false comfort. By industry observations, ransomware operators have changed tactics and increasingly attack the backups themselves. The reasoning is simple: destroy or encrypt the backups and the victim has no way to recover, which raises the odds they'll pay the ransom.

As a result, the backup that's meant to be your insurance becomes the target. A company can dutifully make copies for years — and discover on the day of the attack that they're encrypted along with the primary data, because they sat on the same network with the same access rights. So the question has shifted from "do you make backups?" to "will your backups survive an attack on you?"

Fresh data bears this out. Mandiant's M-Trends 2026 calls it out as a distinct tactic — "recovery denial": before encrypting production systems, prominent groups (Akira, Qilin and others) deliberately take down exactly what a business relies on to recover — backups, identity services, and the virtualization layer. So backups aren't attacked "sometimes"; they're attacked by design, first.

The classic backup rule used to be 3-2-1. Under pressure from ransomware, it evolved into 3-2-1-1-0. Let's go number by number:

• 3 — three copies of your data. The primary data plus at least two backups. One copy isn't a backup — it's an illusion.
• 2 — on two different media types. So that the failure of one storage type doesn't wipe out every copy at once.
• 1 — one copy off-site. A fire, flood, or breach at one location shouldn't destroy everything.
• 1 — one copy immutable or offline. This is the new, critical element: a copy that physically can't be changed or deleted for a set period. This is the one that survives a ransomware attack.
• 0 — zero errors when you test the restore. A backup counts as working only if you've actually restored from it. An untested copy is a hope, not a backup.

The last two digits (1 and 0) are what set modern protection apart from the outdated "a copy is sitting somewhere" approach.

An immutable copy is a backup that can't be changed or deleted for a set period. This is what directly stands up to ransomware: the data is written, but it can't be touched until the period expires.

That shifts the odds in your favor. Even in the worst case — an attacker has gotten into the network and seized the administrator's passwords — in strict mode they can't overwrite or delete the immutable copy. As long as the protection period hasn't expired, you still have a way to recover your data without paying a ransom, given a tested restore.

An important detail people get wrong: immutability comes in different modes. In soft mode an administrator can still lift the protection early — which means an attacker who stole that access can too. Reliable protection comes from strict mode, where no one can remove the lock before the period ends. That's why we configure strict mode by default.

The most painful kind of disaster is when the copies exist but you can't restore from them: a corrupted archive, incomplete data, a forgotten database. That's why the rule includes a "0": regular restore testing. A backup earns "working" status only after a system has actually been deployed from it in a test environment. Anything else is "a copy is sitting there," not "we're protected." We've baked this same principle into our data reliability checklist.

Step by step, how we build backup protection:

1. Inventory. What exactly we back up, how often, and how critical the loss would be (that sets the copy frequency).
2. Local copy for fast recovery from everyday failures.
3. Off-site copy — separate from the main facility (a different location or storage).
4. Immutable copy in strict mode — protection against ransomware and against deletion.
5. Encryption of the copies, so the data is useless if the storage is stolen.
6. Regular restore testing — scheduled deployment from a backup, so "zero errors" is a fact, not a slogan.
7. Access control and logging — who did what with the copies.

The specific parameters (how often to take copies, how fast to restore, how long to lock immutability) are matched to how critical your business is and fixed in the contract — there are no single "right" numbers for everyone.

You can build this protection in-house, or bring in backup as a service (BaaS) — where a provider configures and maintains the copies, immutability, and restore testing. In essence, that's your disaster recovery: a plan prepared in advance for how the business gets back to work after a failure or attack. More on this in infrastructure and backup as a service.

No one likes to think about it, but the cost of having no protection is real: business downtime, loss of accumulated data, a reputational hit, and — in the worst case — paying a ransom with no guarantee the data comes back. Against that, the cost of properly configured backup is usually well below the potential damage. It isn't a "just in case" expense — it's insurance with a clear price against a risk with an unclear one.

• What is the 3-2-1-1-0 rule? Three copies of your data, on two media types, one off-site, one immutable, zero errors when testing the restore. The modern standard for protecting backups from ransomware.
• What is an immutable backup? A copy that can't be overwritten or deleted for a set period; with a correctly configured strict mode practically no one can do it, including the administrator. So ransomware generally won't overwrite or delete it.
• Why isn't an ordinary backup enough against ransomware? Because, by industry observations, attacks often start with the backups. If they sit on the same network with the same rights, they get encrypted along with the primary data.
• How do you recover after ransomware? Deploy the system from the immutable copy the attack didn't touch, after first confirming it's been restore-tested. Then there's no need to pay a ransom.
• Can you recover without paying a ransom? Yes — if you have an intact immutable copy and a tested restore. Then the attack becomes a manageable incident, not a catastrophe.
• Can backup protection be outsourced? Yes — that's backup as a service (BaaS): a provider configures and maintains the copies, immutability, and restore testing. More in infrastructure.
• How often should copies be made and tested? It depends on how much data you can afford to lose in a failure. We match the exact frequency and restore speed to how critical your business is and fix it in the contract.