If you've been backing up data for more than a few years, you already know the 3-2-1 rule: three copies of your data, on two different types of media, with one copy offsite. It's simple enough to remember under pressure, which is exactly why it stuck. But ransomware changed what "safe" means for a backup, and the classic rule was never built to answer the question that actually matters today — can you get that data back if an attacker has already been inside your network for weeks? That's where the 3-2-1-1-0 backup rule comes in: the same foundation, with two extra digits that close the gap 3-2-1 leaves open.
The classic 3-2-1 rule
The 3-2-1 rule was coined by photographer Peter Krogh in the mid-2000s, in his book on managing digital photo libraries, as a way to stop irreplaceable image files from disappearing to a single drive failure. The logic was simple enough that it spread far beyond photography: 3 copies of your data, on 2 different types of media (say, a local disk and a cloud repository), with 1 copy kept offsite so a fire, flood or theft at one location can't take out every copy at once.
For years, that was enough. A local NAS handled the fast-restore copy, an offsite or cloud copy handled disaster recovery, and most single-site failures (hardware death, accidental deletion, a burst pipe) were covered. What it doesn't cover is an attacker who's already inside the network, because "offsite" only helps if the offsite copy is out of that attacker's reach too.
Why the extra 1: immutable and air-gapped
Modern ransomware doesn't just encrypt production data — it goes looking for the backups first, specifically because it knows a working backup is the one thing that lets a business refuse to pay. If your backup repository is reachable from the same network, with the same credentials, as everything else the attacker has already compromised, "offsite" doesn't save you. The extra 1 in 3-2-1-1-0 is a copy that's immutable, air-gapped, or both: a copy that cannot be encrypted, deleted or altered even by an attacker holding valid admin credentials, for a set retention window.
Immutability and air-gapping solve the same problem from different angles. An immutable backup, written to storage with object-lock enabled for example, accepts writes but refuses deletes or overwrites until a retention timer expires, so even a compromised backup admin account can't destroy it early. An air-gapped copy goes further: it physically or logically disconnects the backup from the network between jobs, whether that's tape taken offline or a cloud target the production network has no standing credentials to reach, so there's no live connection for an attacker to ride in on at all. Either one breaks the "encrypt production, then encrypt or delete the backups" playbook that makes modern ransomware attacks so effective.
Why the 0: zero errors, verified
The 3-2-1 rule assumes that if a backup job says "completed successfully", the data is recoverable. That assumption is where most real backup failures actually live — not in the job never running, but in a restore that quietly doesn't work the one time it's tested for real, during an actual outage. The 0 in 3-2-1-1-0 means zero errors, confirmed through regular, automated recovery testing rather than trusted on faith. It replaces "the job completed" with "we proved we can restore from this."
In practice that means booting a copy of the backed-up system in an isolated sandbox on a schedule, not just checking that a backup job's log says success. A completed job confirms the software wrote data somewhere; a verified restore confirms that data is a working system. Those are different claims, and conflating them is how organisations discover, mid-incident, that months of "successful" backups don't actually boot.
Mapping the 3-2-1-1-0 backup rule to real products
The extra 1 and 0 aren't abstract — they map to specific, buyable features. NAKIVO, one of the platforms CRS distributes, writes backups as immutable to Amazon S3, Wasabi, Azure Blob, Backblaze B2 or Linux repositories, which covers the extra 1 without requiring a separate air-gap process. For the 0, NAKIVO runs automated screenshot verification on every backup, confirming the system actually boots from that backup rather than just logging that the job finished — the exact gap the "0" step exists to close.
For the offsite and immutable legs specifically, object storage with lock enabled (Wasabi is one option in the CRS portfolio) is a straightforward way to add an immutable, offsite copy without new hardware. For businesses that want a physical air-gapped layer as well, appliance-based platforms such as StoneFly support disconnected and replicated backup targets built specifically around ransomware recovery. None of these are mutually exclusive: a realistic 3-2-1-1-0 stack for an SMB is usually a local fast-restore copy, a cloud copy with immutability switched on, and a verification job running on a schedule, not three separate platforms bought one at a time.
What this looks like when it fails
The failure mode 3-2-1-1-0 is built to prevent is a familiar one, even without naming a specific incident: a business gets hit by ransomware, and the attacker has been inside the network for weeks before triggering the encryption. In that time, they've found the backup server, because it's on the same domain with the same admin credentials as everything else. The "offsite" copy is really just an offsite destination — still reachable, still writable, still deletable from a compromised account. When the ransomware fires, it encrypts production and then walks straight to the backup repository and does the same thing there, because nothing about the backup itself was any harder to destroy than the data it was protecting.
The other common failure doesn't involve an attacker at all. A backup job runs every night for a year, every log says success, and nobody restores from it until the day they actually need to — at which point a corrupted index, an incompatible application version, or a silently-failed database consistency check turns "we have backups" into "we thought we had backups." Both failures are 3-2-1-compliant right up until the moment they aren't. Both are exactly what the extra 1 and 0 exist to catch.
Quick checklist: is your backup actually 3-2-1-1-0?
Run your current setup against each digit before assuming it already qualifies:
- 3 copies — production data plus two backups, not production plus one backup you're counting twice.
- 2 media types — genuinely different storage, not two folders on the same NAS or two buckets with the same provider and the same credentials.
- 1 offsite — a copy that survives a fire, flood or theft at the primary site, not a second server in the same rack.
- 1 immutable or air-gapped — a copy the production network cannot write to, delete from, or reach with standing credentials, for a defined retention window.
- 0 errors, verified — a scheduled test restore that confirms the system actually boots, on a calendar, not a backup job log you've never questioned.
Most SMBs pass the first three without trying — the last two are where the gaps usually are, and they're also the two an attacker is counting on you never checking.
Getting there without overhauling everything
None of this requires ripping out an existing backup platform. Most SMBs already have most of 3-2-1 in place — a local copy and a cloud or offsite copy are standard practice by now. Getting to 3-2-1-1-0 is usually a case of turning on immutability where the platform already supports it, choosing at least one storage target the production network doesn't have standing write access to, and scheduling recovery tests instead of trusting job logs. It's a configuration change and a process change more often than it's a new purchase.
If you're weighing up where your current setup sits against this model, our backup and disaster recovery solutions page covers the platforms CRS distributes across each leg of 3-2-1-1-0, and our ransomware protection page goes deeper on the attack patterns the extra 1 and 0 are specifically designed to defeat. For the broader immutable-copy strategy this rule builds on, see our guide to the 3-2-1-1 backup strategy and how to be sure your backups actually survive a ransomware attack. Get in touch if you'd like help mapping your current backup setup against each digit in the rule.