The 3-2-1 backup rule and 3-2-1-1-0, explained
The 3-2-1 rule says to keep three copies of your data (the original plus two backups), on two different kinds of storage, with one copy in a different location. The extension 3-2-1-1-0 adds one copy that is immutable or offline and zero errors after a verified recovery test. Both are planning heuristics, not standards: they tell you which failures to design against, not which product to buy.
By Lucas Flores, IT Systeme Flores UG. Last updated
What do the three numbers in 3-2-1 mean?
The rule is three short instructions, and each one is aimed at one way of losing data.
| Number | Instruction | What it protects against |
|---|---|---|
| 3 | Keep three copies of the data: the original and two backups. | A single backup that is damaged, incomplete or unreadable on the day you need it. |
| 2 | Keep the copies on two different kinds of storage. | One weakness shared by every copy: the same disk model, controller, firmware bug, file system or storage service. |
| 1 | Keep one copy in a different location. | Fire, flood, theft, a provider outage, or one lost account that reaches everything in one place. |
"Copy" means an independent copy. A folder that syncs to another disk or to a cloud drive mirrors every change, including a deletion or an overwrite, so it is a second location of the live data, not a backup copy.
Where does the 3-2-1 rule come from?
The rule is commonly attributed to the photographer Peter Krogh, who sets it out in his book The DAM Book: Digital Asset Management for Photographers. The US-CERT paper Data Backup Options (2012) states the rule as three instructions and cites page 207 of the book's second edition (O'Reilly Media, 2009).
The book's first edition appeared in 2005. This page does not claim that the rule was already in it, because we did not check the first edition. What can be said is that the rule has no standards body behind it: it is advice that agencies and vendors have repeated widely.
What does 3-2-1-1-0 add?
The extension adds two numbers. Veeam describes it and has popularised it; it is not a standard, and other number strings in circulation have no agreed definition. Read the definition a source gives before you rely on a variant.
| Number | Instruction | What it protects against |
|---|---|---|
| 1 (the second one) | Keep one copy that is immutable or offline. | A backup that is deleted or encrypted by whoever takes over the backup system or the administrator account. |
| 0 | Reach zero errors after verified recovery. | A backup that was written without an error but cannot be restored. |
Immutable means the storage enforces that the data cannot be changed or deleted for a set period. Amazon S3 Object Lock is a widely used example: it uses a write-once-read-many (WORM) model, and in compliance mode no user, not even the root user of the account, can delete a locked object version before its retention period ends. Offline or air-gapped means the copy is disconnected when it is not being written; NIST describes an air gap as an interface between two systems that are not connected physically, where any logical connection is not automated.
Zero errors is about verification. A backup counts as good only after it has been read back, and recovery has been tried. It does not promise that nothing ever goes wrong; it means that no unverified backup is taken for a good one and that every failure is dealt with. See how to prove that a backup can be restored.
How can a small business with Microsoft 365 apply the rule?
This is an example for a business with 25 users on Exchange Online and OneDrive. The numbers are illustrative; the shape is what matters. If you also use SharePoint or Teams, check that your backup tool covers them: the rule applies to every data set on its own.
An example layout for 3-2-1-1-0 with Microsoft 365
The live data plus two backups, with the second location, the immutable copy and the restore check marked.
Example only. Provider names are placeholders; any two independent providers or sites fit.
| Copy | What it is | Where it lives | Which instruction it serves |
|---|---|---|---|
| 1 | The live mailboxes and OneDrive accounts | Microsoft 365 | The original, the first of the three copies. |
| 2 | A nightly backup | Object storage at a provider and under a login that is not part of the Microsoft 365 tenant | The second copy, on object storage, in another location than Microsoft's cloud. |
| 3 | A second backup of the same data | A NAS in the office (an NFS share), or a bucket at a second provider | The third copy, on a different kind of storage, at a different site. This one is kept immutable or offline. |
Copy 1 is the live data. Microsoft keeps it available with its own replication, but that is not a copy you can restore from on demand beyond recycle bins and retention. See Does Microsoft 365 back up your data?
Copy 2 is a backup you control. Independence matters more than distance: if one compromised administrator account can delete the live data and the backups, they are one failure domain, however far apart the servers are. Use a different provider and a different login from the Microsoft 365 tenant.
Copy 3 sits somewhere else, on something else. A NAS in the office and a bucket at a provider are two kinds of storage at two sites, so this layout meets the "two kinds of storage" and "one other location" instructions with room to spare. Make this the copy that is immutable or offline: a bucket with Object Lock, or a disk that is disconnected after the job and rotated. Whether your backup tool can write to such storage without breaking its own cleanup is a question to test before you rely on it. How governance and compliance mode differ, and what an offline copy adds, is in immutable backups, WORM, air gaps and ransomware.
The zero is a routine. Every week, read a sample of each backup back and compare it with the checksums recorded when the backup was made, and once a quarter restore one mailbox into a test mailbox and compare. That rhythm is our suggestion, not a rule from a standard.
What does the 3-2-1 rule not cover?
The rule says how many copies and where they live. It leaves several questions open, and a plan needs an answer to each:
- How often to back up, which is your recovery point objective (RPO); see RPO and RTO explained.
- How fast you must be back, which is your recovery time objective (RTO).
- How long to keep restore points, which is retention; see grandfather-father-son rotation.
- Who may delete or change backups, and with which credentials.
- Whether the backups work, which is verification, and whether you still hold the encryption keys: a copy that you cannot decrypt is not a copy.
Treat the rule as the start of a plan, not as the plan.
Does the rule still make sense with cloud storage?
Yes, if you read "two kinds of storage" as "two failure domains". The wording dates from disks and tapes; with cloud storage the intent behind the numbers, independence, is what remains. Two buckets at one provider, in one account, share a provider, a login and a billing relationship, so one incident can reach both. Two buckets at different providers, or a bucket and a disk in your own office, do not. For how local disk, NAS, object storage and tape compare on cost, durability and restore speed, see choosing backup storage.
How Restow handles this
Restow helps with the copies, with the zero and, since 0.4.0, with the immutable copy, and it states where each of them stops. In detail:
The "0": recovery readiness
Every week Restow draws a random sample from the newest backup of each mailbox, OneDrive, SharePoint site and IMAP account (20 mails, 20 files and a few calendar entries and contacts), reads it back through the restore path, including decryption, and compares it with the SHA-256 checksums recorded when the backup was made. A backup that has not been checked shows as Unverified, never green. It is a sample, and the check does not restore into a live mailbox. Servers, clients and file shares are checked after every new backup: up to 20 sampled files are read back and compared. Proxmox VE guests (a preview) are read back within minutes of every new restore point (since 0.4.2) and can also be boot-tested, which restores the newest restore point as an isolated temporary guest and checks that it starts. A full test restore into a separate target for every kind of backup is planned. See how Restow proves that backups can be restored and the verification page.
Storage you choose
Backups go to a repository you pick: a local disk, S3-compatible object storage (with a preset for Hetzner Object Storage) or an NFS share. There is no Restow-run cloud. The NFS mount from the web interface and the Hetzner preset have not been tested against a real NFS server or a real Hetzner bucket yet. An SMB share or NFS export is something Restow backs up, not somewhere it stores to; see file shares (SMB and NFS). For the storage, see storage.
A second copy
Restow can write the second copy itself. A tenant's repositories have roles: the primary receives every new backup first, and any number of copy repositories receive the same data. Data that was written before a copy existed is mirrored onto it during the weekly storage check and verified by SHA-256. This covers mail, calendar, contacts, OneDrive, SharePoint, IMAP and Proxmox VE VM data. It does not cover servers and clients, file shares or Proxmox VE containers: their backups stay in the primary repository. For a file share, a copy job into another share is labelled "Not a backup: no versions on the target", so it is a second place for the current files, not a second backup. Restow cannot tell whether a copy shares a failure domain with the primary; choosing another provider or site is your decision.
The immutable copy
Since 0.4.0 every repository has an immutability setting, off until an administrator turns it on. On an S3 bucket created with Object Lock (compliance or governance mode, 1 to 3650 days) the storage itself refuses to delete or overwrite locked backup data before its date. A copy repository on such a bucket at another provider is therefore the immutable copy of 3-2-1-1-0 for the data that copy repositories cover. For servers, clients, file shares and Proxmox VE containers, which stay in the primary repository, the primary itself has to be the immutable one, and the installation's default repository cannot be made immutable: give the tenant a repository of its own. A local disk or an NFS share gets only a deletion delay that Restow enforces itself, which is not immutability. Object Lock can only be enabled when a bucket is created. It was tested against a simulated S3 service, not yet against a real one, and we have not tested Restow against a bucket with a default Object Lock retention, so treat that combination as untested. What is locked, what is not and what it does not protect against is on the storage page and in immutable backups, WORM, air gaps and ransomware. For servers and clients Restow also enforces append-only on the server: a compromised machine can add backups but cannot delete them. That protects against the machine; the lock is what protects against someone with access to the Restow server or the storage key, while someone who controls Restow can still stop new locks.
Frequently asked questions
Is the 3-2-1 backup rule a standard?
No. It is practical advice, commonly attributed to the photographer Peter Krogh and repeated since by agencies and vendors. The 3-2-1-1-0 extension is described by Veeam and is not a standard either, so check how a source defines a variant before you rely on it.
Does the live data in Microsoft 365 count as one of the three copies?
It counts as copy number one, the original. Microsoft keeps it available with its own replication, but what you can restore yourself is limited to recycle bins, version history and retention settings with fixed time windows. The two backups of the rule come on top of the live data, not instead of it.
Do two backups in the same cloud account satisfy 3-2-1?
They are two copies, but not independent ones. The same account, the same provider and the same administrator credentials form one failure domain, so one mistake or one compromised login can reach both. Put the second backup at another provider or in another location, with separate credentials.
What does zero errors mean in 3-2-1-1-0?
It means the backups are verified: each one is checked after it is made, and recovery has actually been tried, with no unresolved errors. It does not promise that nothing ever fails. It says that a backup does not count as good until it has been read back, and that failures get fixed.
How often should I test restores?
There is no standard interval. Our suggestion is to read a sample of the newest backup back every week and to run a full restore drill into a test target every quarter and after any change to storage, keys or the backup tool. Your own risk and your customers' contracts may ask for more.
Sources
Read on 21 October 2026.
- Ruggiero, P. and Heckathorn, M.: Data Backup Options (US-CERT, Carnegie Mellon University, 2012). States the 3-2-1 rule and cites Krogh for it
- Krogh, P.: The DAM Book: Digital Asset Management for Photographers, 2nd edition (O'Reilly Media, 2009). The book that US-CERT cites, page 207, for the rule
- Veeam: The 3-2-1 backup rule. Describes 3-2-1-1-0 as an extension with an immutable or air-gapped copy and zero recovery errors
- Amazon S3 User Guide: Locking objects with Object Lock. The write-once-read-many model and compliance mode
- NIST glossary: air gap. Definition of an air gap