The classic 3-2-1 rule — three copies, two media types, one offsite — is necessary but no longer sufficient, because ransomware now hunts and encrypts backups first. The 2026 version is 3-2-1-1-0: add one immutable or offline copy an attacker can't alter, and zero errors on a verified restore test. The restore test is the part almost everyone skips, and it's the part that decides whether your backup is real.
Every ransomware recovery we've run divides cleanly into two groups: companies whose backups survived, and companies who thought they had backups. The difference is rarely the backup software — it's whether the backups were reachable by the attacker and whether anyone had ever actually restored from them. The 3-2-1 rule you learned is a good start and a dangerous finish. Here's how it evolved, and how to close the gap in a week. It's the backbone of real disaster recovery.
What 3-2-1 got right — and the hole time opened in it
3-2-1 is elegant: 3 copies of your data, on 2 different media types, with 1 copy offsite. It defends against the failures of its era — a dead drive, a fire, a flood, a stolen laptop. Against hardware and disaster, it still holds. The hole is that it was designed for a world where backups failed passively. Modern ransomware fails them actively: today's crews, once inside, specifically seek out backup servers, network shares, and cloud backup consoles and encrypt or delete them before triggering the visible attack — because they know your backups are the one thing that lets you refuse to pay. A perfectly compliant 3-2-1 setup where all three copies are reachable with the admin credentials the attacker just stole is three copies of nothing.
The 2026 rule: 3-2-1-1-0
The fourth number — one immutable or offline copy — is the ransomware defense. Immutable means write-once-read-many: even an attacker with full admin rights cannot alter or delete it within its retention window. Offline (or "air-gapped") means physically or logically disconnected — tape rotated out, a copy in cloud object storage with an object-lock the console can't override, a device that's only connected during the backup window. This is the copy that survives when everything reachable is encrypted. The fifth number — zero — is the reality check: a restore, tested and verified, with no errors. It's last in the sequence and first in importance.
Why "0" — the verified restore — is the number that matters
A backup is a promise; a restore is a fact. In our engagements, silent backup failure is depressingly common: the job reported success for months while backing up an empty folder, an excluded database, or a corrupted image nobody opened. You find out at the exact moment you can least afford to — mid-incident, with the business down. The discipline that prevents this is boring and non-negotiable: on a schedule (quarterly at minimum), actually restore real data to a real place and confirm it works, and time it while you're there so your recovery estimate is measured, not imagined. A backup you have never restored from is not a backup; it's a hypothesis. Testing it is how the "0" gets earned.
Two numbers your leadership must actually agree on: RPO and RTO
Backup design is meaningless without two business decisions written down. RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time — if you back up nightly, your RPO is up to 24 hours, and a Tuesday-afternoon attack loses Tuesday. RTO (Recovery Time Objective) is how long you can afford to be down. These aren't IT numbers; they're business numbers, and the classic failure is that nobody set them, so "as often as convenient" and "as fast as possible" become the accidental policy — discovered to be inadequate only during the outage. Set them explicitly, then build backups that meet them. A clinic that can't lose more than an hour of records needs a very different design than an office that can lose a day — and both need leadership to have said so on the record.
A one-week upgrade path
You don't need a project to close the ransomware gap. Day 1: answer one question honestly — from a machine with your normal admin credentials, can you reach, alter, or delete your backups? If yes, so can ransomware. Days 2–3: add the immutable/offline copy — cloud object storage with object-lock is the fastest route for most SMBs; retention set beyond your detection window. Day 4: run a real restore of something meaningful and time it; write down what breaks. Day 5: get RPO and RTO agreed by whoever owns the business risk, and set the restore test on a recurring calendar with a named owner. That's the difference between the two groups in every ransomware story — and it's a week, not a quarter. When the incident comes, this is what turns our first-24-hours playbook into a two-hour story instead of a two-week one.
Four backup myths we still meet in 2026
"We're in the cloud, so we're backed up." Your SaaS provider keeps the service running; that is not the same as a recoverable backup of your data you can restore on your terms — and it's usually reachable and deletable with the credentials an attacker steals. Cloud is a location, not a backup strategy. "RAID is a backup." RAID protects against a disk dying; it faithfully replicates ransomware, accidental deletion, and corruption across every disk instantly. Different problem. "Backups ran successfully, so we're fine." "Success" means the job completed, not that the data is complete and restorable — the silent failure (empty folder, excluded database, corrupt image) reports success for months. Only a restore test finds it. "We'll just pay if it comes to that." Payment doesn't guarantee working decryption, doesn't un-steal exfiltrated data, may be legally fraught, and marks you as a payer — as we cover in the ransomware playbook. Good backups are what let you refuse the question entirely. Each myth feels reasonable, and each one is the story a company tells itself right up until the morning it doesn't hold.
What this costs, honestly
The upgrade from "3-2-1 on paper" to "3-2-1-1-0 that survives ransomware" is one of the cheapest high-impact moves in security. The immutable copy is typically a setting on storage you may already pay for (object-lock on cloud object storage), or a modest addition — for most SMBs it lands in the low tens of dollars per month at the data volumes involved. The restore test costs time, not money: an hour a quarter from whoever owns backups. Against the alternative — a ransomware recovery measured in weeks, or a business that simply doesn't come back — the return is not a close call. The reason companies skip it isn't cost; it's that backups are invisible until the day they're everything, and invisible work loses the calendar fight to visible work. Naming an owner and a recurring date is how it stops losing.
Where backups fit in the bigger security picture
Backups are the last line, not the only one, and treating them as either extreme is a mistake. Lean too hard on "we have backups" and you neglect the prevention that stops the incident in the first place — MFA, patching, EDR, the controls in our baseline checklist. Neglect backups and you're betting your entire business on never being breached, which is not a bet serious people make. The right frame: prevention reduces how often you get hit, and ransomware-proof backups decide whether a hit is a bad afternoon or a bad quarter. They're also increasingly a line item on the forms — cyber insurers ask specifically about offline or immutable backups and tested restores, as we cover in the insurance requirements guide, because underwriters learned the hard way that a company with real backups rarely files the catastrophic claim. Build both layers; they're answering different questions, and you need both answers to be yes.
Frequently asked questions
Is cloud backup automatically immutable?
No — not by default. Standard cloud backup is reachable and deletable with the right credentials, which is exactly what an attacker steals. You must explicitly enable immutability (object-lock / write-once retention) so that even an admin can't alter the copy within its window. Turning it on is usually a setting, not a new product.
What counts as "offline" if we're fully cloud?
Logical isolation achieves the goal without tape: object storage with an enforced object-lock the backup console itself cannot override, a separate account with independent credentials, or a provider whose immutability can't be disabled during the retention period. The test is simple — could a compromise of your main admin account reach and destroy this copy? If no, it qualifies.
How often should we test restores?
Quarterly at minimum, and after any significant change to systems or backup configuration. Restore something real, verify it works, and time it. Many organizations discover their first silent failure during the first honest test — which is precisely the point of doing it on a calendar rather than during a crisis.
Does this replace an incident response plan?
No — it's the foundation that makes one work. Great backups shorten recovery dramatically, but you still need the plan for containment, eradication, notification, and the order of restoration. Backups decide whether you can recover; the plan decides how fast and how cleanly. You want both.
We're a 15-person company — isn't this overkill?
The opposite — small companies are the primary ransomware target precisely because their backups are usually reachable and untested. The immutable copy and the quarterly restore are cheap and fast at your size, and they're the specific controls that turn a potential business-ending event into a bad afternoon.
Pressure-test our backups Our backup & recovery
General guidance from our disaster-recovery engagements. "3-2-1-1-0" is a widely used industry evolution of the original 3-2-1 rule; your RPO/RTO and design should be set to your business's real tolerances.