The 3-2-1-1-0 backup rule, explained

Three copies of your data, on two kinds of storage, one of them offsite, one of them impossible to change or delete, and zero errors when you test a restore. Each number closes a specific way backups fail. This guide goes through them one by one, with the mistakes that make a setup look compliant when it isn't.

Where the rule comes from

The original 3-2-1 rule was popularized by photographer Peter Krogh in The DAM Book: Digital Asset Management for Photographers. It was written for photo libraries, but the logic applies to any data: keep enough copies, in enough different places, that no single failure takes all of them.

The extension to 3-2-1-1-0 comes from Veeam, the backup software company. It adds one copy that is immutable, air-gapped or offline, and a requirement that recovery is verified with zero errors.

Each digit, and the usual mistake

#	Rule	The mistake that breaks it
3	At least three copies: the live data plus two backups.	Counting RAID, mirroring or file sync as a copy. They replicate deletions, corruption and encryption instantly, so they protect against disk failure, not data loss.
2	On two different kinds of storage, so one failure mode can't reach every copy.	Two backups on the same array, the same server, or two buckets in the same cloud account. Different folders are not different media.
1	One copy offsite, in a different building or region.	An offsite copy that can be reached with the same credentials as the server it protects. Distance doesn't help if one stolen password reaches both.
1	One copy that is immutable, air-gapped or offline: it can't be changed or deleted during the retention period.	Calling snapshots or versioning "immutable" when the same admin account, or the backup job's own key, can delete them.
0	Zero errors: backups are checked for integrity, and restores are actually tested.	Treating "job completed" as proof. A job can succeed while backing up an empty directory, a stale database dump or a corrupted archive.

The test for the immutable copy is simple: the credential that writes new backups must not be able to delete existing ones. If it can, anyone who takes over the server can erase every copy in the same incident.

Why 3-2-1 stopped being enough

3-2-1 was designed for hardware failure, theft and site disasters. It says nothing about an attacker who is already inside your network with your credentials.

That is now the normal ransomware playbook. CISA, the US cybersecurity agency, notes in its #StopRansomware Guide that many ransomware variants look for reachable backups and delete or encrypt them so that restoring is impossible without paying. Its recommendation is to keep offline, encrypted backups of critical data and to test them regularly in a disaster recovery scenario.

The extra 1 answers the first half of that: a copy the attacker can't touch. The 0 answers the second: proof the copy will actually restore.

A worked example

A single Linux server running websites and databases, protected to 3-2-1-1-0 with open-source tools:

Digit	How it's met
Copy 1	The live server.
Copy 2	Nightly backup to a separate disk or NAS on the same site, for fast restores.
Copy 3, offsite	Nightly restic backup to storage at a different provider, in a different region.
Immutable	The offsite repository is served by restic's rest-server in `--append-only` mode, which allows new backups but prevents deletion and modification of existing ones. Old snapshots are removed from a separate, well-secured machine with a time-based policy (`restic forget --keep-within`), never from the server being backed up. restic warns that count-based policies such as "keep three weekly" can be gamed with fake snapshots on an append-only repository.
Zero errors	A weekly `restic check` that also reads a rotating slice of the stored data, plus a monthly test restore of one real site to a scratch location, with the result written down.

# On the storage host: new backups allowed, deletes refused
rest-server --path /srv/restic --append-only --private-repos

# On the server, weekly: structure check plus a different tenth of the data
# each week, so every byte is read once every ten weeks
restic -r rest:https://user:pass@backup.example.com/user/ \
  check --read-data-subset=$(( 10#$(date +%V) % 10 + 1 ))/10

Two choices in this setup do most of the work. The offsite copy is at a different provider, so one account suspension or regional outage can't take copies 2 and 3 together. And the server's backup credential can add snapshots but not remove them.

Ten-question self-check

Answer for your own setup. Every "no" is a gap in one of the digits.

Do you have at least two backup copies besides the live data, not counting RAID or sync?
Are those copies on different storage systems, not just different folders or volumes?
Is at least one copy at a different provider, building or region?
Would losing one cloud account or one provider still leave you a usable copy?
Is there a copy that the backed-up server's own credentials cannot delete?
Is that copy protected for a set period, so even an admin can't shorten it on a whim?
Do you run integrity checks on the stored backups, not just on the backup job?
Have you restored real data from each tier in the last three months?
Would you notice within a day if a backup job silently stopped running?
Could you show a customer or auditor when each tier last succeeded?

Keeping it true

A setup that meets 3-2-1-1-0 on the day it's built rarely stays that way. A job stops after an update, a disk fills up, a credential gets rotated and the offsite copy quietly falls weeks behind. Nothing alerts, because nothing failed loudly; the job just stopped reporting.

That's what Servatum is being built for: it expects each tier on schedule, flags the one that goes silent, and keeps a dated record you can show. It isn't live yet.

Want to know when it is? Join the waitlist.

Join the waitlist