The 3-2-1 Backup Rule, Explained Properly
A rule everyone quotes and few implement precisely. Here's what it actually requires, and where it needs an update for the ransomware era.
What the numbers actually mean
3 — keep three total copies of your data. The production copy counts as one of the three; you need two backup copies beyond it, not three additional copies.
2 — store those copies on two different types of media or storage systems. Two backups sitting on the same NAS, even in different folders, don't satisfy this — a single controller failure, firmware bug, or storage-array-wide event takes out both. Disk plus tape, or on-prem NAS plus cloud object storage, are the common real implementations.
1 — keep one copy offsite, physically or logically separate from your primary location. This protects against site-level events: fire, flood, theft, or a full building power/network failure that a same-room backup doesn't survive.
A common misreading
Some teams read "3 copies" as "production plus 3 backups" — that's a stricter (and more expensive) interpretation than the rule requires, but not wrong to do if the budget allows it. Just be clear with your own team about which interpretation you're actually running, since it changes the storage math by 50%.
Where 3-2-1 falls short today
The rule predates ransomware being a mainstream operational threat. A textbook 3-2-1 setup can still fail against ransomware if the "offsite" copy is a live, network-mounted target — the same malware that encrypts production can walk straight over to a mapped or continuously-synced offsite share and encrypt that too, especially if it uses the same credentials or a domain-joined path.
This is why the modern extension, 3-2-1-1, adds a fourth requirement: at least one copy must be immutable or air-gapped — offline, write-once (WORM), or protected by object-lock/immutability features that even an administrator credential can't alter or delete within the retention window. Most modern cloud object storage (S3 Object Lock and equivalents) and several backup software products now support this directly, so it's usually a configuration change rather than a new tool purchase.
Sizing the storage in practice
Full backups repeat the entire dataset every run — simple, but expensive over long retention windows. Incremental backups store one full backup plus only the changed data on each subsequent run, which is far more space-efficient for daily backups with a modest daily change rate (commonly 3-5% for general file/database servers), at the cost of a longer restore chain — every restore needs the full backup plus every incremental since.
Run the numbers for your own retention window, backup type, and change rate with the Backup Retention & 3-2-1 Calculator — it estimates total chain storage and the full 3-2-1 footprint.