Keep three copies of your data, on two different kinds of storage media, with one copy offsite. The production data counts as one of the three, so the rule means the original plus two backups. It answers accidents completely. It does not answer an attacker holding credentials that can write to the backups.
- Three copies means the original data and two backups
- Two media types means two failure modes, not two disks
- One offsite means a single event cannot reach both locations
- Ransomware reaches anything writable, including every backup
- The modern form is 3-2-1-1-0: add immutable, add verified
On this page
The three numbersWhat each number actually means
Every part of the backup rule is a defense against a specific way of losing data, and reading the strategy that way makes the design decisions obvious.
Three copies of the data. The data you work on counts as the first copy. Two backups follow, which means two independent chances that a copy of the data survives whatever happened.
Three is not arbitrary: with a single backup, a failure during recovery leaves you with nothing at all, and that failure is common enough that the second backup copy earns its cost.
Two different types of storage media. This is the part almost everyone abbreviates, and it is the part of the strategy that carries the most weight. Two backup copies on two disks from the same batch in the same server share a failure mode.
Two copies in the same cloud storage account share an account. The intent is that a single class of risk, a controller, a firmware bug, a billing dispute, an administrator error, cannot reach both copies of the data.
In current practice this usually reads as one backup on local storage and one in an unrelated cloud service, not as tape media versus disk the way it did in 2005.
| The two copies | Satisfies the 2 | Why |
|---|---|---|
| Local NAS and cloud object storage | Yes | Nothing shared but the data itself |
| Local NAS and a second NAS from another vendor | Yes | Different firmware, different failure modes |
| Backup appliance and rotated external drives | Yes | One is offline whenever it is unplugged |
| Two buckets in one cloud account | No | One account reaches both |
| Two disks in the same server | No | One controller, one chassis, one power supply |
| Two external drives from the same batch | No | Same model, same age, same firmware bug |
| A snapshot and the volume it was taken from | No | The snapshot lives on the storage it protects |
One backup copy offsite. Every copy of the data inside one building shares the fate of that building. Fire, flood, theft and a burst pipe do not care how many disks you own.
An offsite backup can be cloud storage, a replicated appliance in a second office, or physical media rotated to a different address, and the meaningful test is whether a single physical event can reach both locations.
The three requirements multiply rather than add. A single event has to defeat the redundancy, the media diversity and the geography at the same time, and very few events can. That multiplication is the whole of the strategy, and it is why the rule has outlasted every storage technology it was written for.
OriginWhere the rule came from, and what changed
The rule was popularized by the photographer Peter Krogh, who wrote it down for people managing digital photo archives, where the loss of the data is permanent and there is no vendor to escalate to. It spread from photography into IT data protection because the reasoning about redundancy holds across any kind of data anyone cares about keeping.
It was written for a world where data was lost by accident. Disks failed, buildings burned, people deleted the wrong directory, and every one of those is a random event that hits one thing at a time. Against random events, backup copies are a complete answer.
Ransomware is not a random event, and that is the whole difficulty for a backup strategy built on redundancy alone. An attacker with access to a server looks for the backups first, because the backups are what makes the ransom optional.
Automated backup jobs run with credentials that have write access to the backup storage, and any storage that is writable is reachable. A textbook 3-2-1 backup setup with three copies, two media types and an offsite replica can be encrypted in all three places by an attacker patient enough to wait for the replication to run.
The modern response is the same rule with one addition: at least one backup copy that cannot be modified, even by an administrator with full access, for a defined retention window.
That is what object lock, immutable snapshots and offline media provide, and it is the difference between a backup that survives a security incident and one that gets encrypted along with the rest of the data.
Worked exampleWhat 3-2-1 looks like for a small business
The rule is often quoted and rarely made concrete, so here is a data protection strategy that satisfies it for an organization of about forty people, with the risk each part covers.
| Copy | Where it lives | What it survives |
|---|---|---|
| Production | The file server and the line of business database | Nothing, this is the copy at risk |
| Backup 1 | A local backup appliance or a dedicated NAS | Disk failure, deletion, a bad update |
| Backup 2 | Cloud object storage in a separate provider account | Fire, flood, theft, loss of the building |
| The lock | Object lock on the cloud backup for 30 days | An administrator account compromise |
The local backup exists for recovery speed. Restoring a deleted folder or a broken database from a storage device on the same network takes minutes, and the overwhelming majority of recovery work is exactly that kind of small, boring restore.
The cloud backup exists for the day the building is unavailable. Recovery from it is slower, sometimes by a lot, and that is acceptable because it is the copy of the data you need least often.
The lock exists for the day the credentials are not yours any more. Without it, both backups are only as secure as the account with write access to them, which makes the whole strategy a security question rather than a storage one.
What the strategy covers matters as much as how many copies it makes. The list for an organization of that size runs past the file server: the line of business database and its transaction logs, the virtual machine images, the configuration of the network devices, the certificates, and the cloud mailboxes that nobody thinks of as data until they are gone.
Anything left off that list is not protected by the backup rule no matter how well the rule is followed for everything else, and the omissions are usually discovered during a recovery.
VariantsThe variants, and whether they are worth it
Three extensions of the backup rule show up regularly across vendor documentation, and they are refinements of the same strategy rather than replacements for it.
3-2-1-1-0. The original rule, plus one backup copy that is immutable or offline, plus zero errors when the backups are verified.
It is the version most data protection vendors now recommend across enterprise and small business environments alike, and the extra 1 is the ransomware answer described above. The 0 is the more quietly important one, because a backup that has never been restored is a hypothesis about recovery, not a backup.
4-3-2. Four copies of the data, three locations, two of them offsite. This level of redundancy belongs to managed service providers and regulated environments rather than to ordinary organizations. It exists because two offsite backups held by different providers remove the last shared dependency, which is the offsite storage provider itself.
3-2-1 with a cloud caveat. A backup in the same cloud account as the production data is not really a second location for the risk that matters most, which is the account itself. If production runs in a cloud provider, the offsite copy belongs in a separate account at minimum, and ideally at a separate provider.
The gapsWhat the rule does not cover
The 3-2-1 backup rule answers how many copies of the data exist and where they sit. It says nothing about four questions that decide whether recovery actually works, and every one of them has ended organizations that had backups running the whole time.
How long you keep them. A rule about copies is not a rule about history. Ransomware often sits undetected for weeks, and a backup rotation that keeps fourteen days will faithfully hold fourteen days of already encrypted data. Backup retention has to outlast the time it takes the security team to notice.
Whether recovery works. Backup software reports success when it finished writing, which is not the same as the data being readable, complete and consistent. The only proof is a restore, performed on a schedule, to storage other than the original.
How long recovery takes. Restoring in full from cloud object storage over a business internet connection is measured in days for anything large. If the organization cannot be down that long, the backup rule is satisfied and the recovery plan still fails.
That last one has a name worth knowing, because it turns an argument into a number. The recovery time objective is how long the business can be down before the loss becomes serious, and the recovery point objective is how much data loss is acceptable, measured in time since the last backup.
A nightly backup sets a recovery point objective of one day, which means a failure at four in the afternoon loses a day of work.
Both numbers are decisions for the business rather than for whoever runs the backup software, and writing them down is what turns a backup strategy into a recovery plan.
What data is actually being backed up. Endpoint data, cloud mailboxes and files spread across a software as a service platform are usually outside whatever data protection the server backup provides. Those providers replicate for their own availability, which protects against their storage failing, not against your user deleting a folder.
PitfallsWhere people go wrong
Counting three backups instead of three copies. The production data is the first copy. Three backups is fine and more than the rule asks for, but the arithmetic matters when someone is budgeting for storage.
Two copies on the same kind of storage media. Two external drives from the same batch, or two buckets in one cloud storage account, satisfy the number and defeat the intent, because redundancy across identical things is not redundancy at all.
Calling a second building offsite when it is on the same campus. The test is whether a single physical event reaches both locations, and two buildings across one site fail that test for fire and for flood.
Treating a sync service as a backup. File sync propagates changes to the data, including deletions and encryption, to every device within minutes. Versioning helps and is not the same as an independent backup copy.
Never testing recovery. The most common data protection failure by a wide margin. The job runs green for two years, and the first attempt to restore the data is the day recovery has to work.
Assuming a cloud platform backs up your data. A cloud mailbox or file platform is replicated for the provider's own availability, which is not a backup of your data. Deleted item policies expire, and after that the data is gone.
Leaving the backup credentials in the domain. An account that can write to the backup storage, held in the same directory as every other account, is one security compromise away from belonging to the attacker. Backup credentials belong outside the directory that the rest of the organization authenticates against.
ComparisonThe rule and its two extensions, by what each one survives
| Criterion | 3-2-1 | 3-2-1-1-0 | 4-3-2 |
|---|---|---|---|
| Total copies | 3 | 3 | 4 |
| Off site copies | 1 | 1 | 2 |
| Immutable or offline copy | No | Yes | Yes |
| Verification required | No | Yes | Usually |
| Survives a disk failure | Yes | Yes | Yes |
| Survives losing the building | Yes | Yes | Yes |
| Survives an administrator compromise | No | Yes | Yes |
| Reasonable for a small business | Yes | Yes | No |
The last three rows are the whole argument. The classic backup rule handles accidents completely and handles a determined attacker with access to the network not at all, and the immutable copy is what closes that gap in a modern data protection strategy.
FAQFrequently asked questions
What is the 3-2-1 backup rule?
Keep three copies of your data, on two different types of storage, with one copy offsite. The production data is the first of the three copies.
Does the original file count as one of the three copies?
Yes. The rule means the live data plus two backups, so a setup with two backups already satisfies the number.
What counts as two different media types?
Two storage systems that do not share a failure mode. Local disk plus cloud object storage is the usual modern answer. Two disks in the same server is not.
How far away does the offsite copy need to be?
Far enough that one fire, flood or break in cannot reach both locations. A different building on the same site does not qualify.
Does the cloud count as offsite?
Yes, provided it is not the same account or the same provider as the production system. If the workload already runs in a cloud, the backup belongs somewhere the same credentials cannot reach.
Is 3-2-1 enough to survive ransomware?
Not by itself. Redundancy answers accidents, and a security incident is not an accident. Attackers target the backups, and anything writable can be encrypted. Add at least one immutable or offline copy, which is the extra 1 in 3-2-1-1-0.
What is an immutable backup?
A copy that cannot be changed or deleted for a set retention period, enforced by the storage rather than by permissions. Object lock in cloud storage is the common form.
What does the 0 in 3-2-1-1-0 mean?
Zero errors when the backups are verified. It exists because backup software reporting success is not evidence that a restore will work.
How often should I test a restore?
Quarterly for a full system, monthly for individual files. Test to different hardware than the original, because restoring to the source machine hides an entire class of problem.
How long should backups be retained?
Longer than it takes to notice a problem. Ransomware frequently goes undetected for weeks, so a rotation shorter than that will hold only compromised data by the time it is needed.
Does 3-2-1 apply to a cloud mailbox or a file platform?
Yes, and it is usually the biggest gap in small organizations. The provider replicates for its own availability, which does not protect against your user deleting a folder or an attacker doing it deliberately.
Is RAID a backup?
No. RAID is redundancy inside one machine: it protects against a disk failing and keeps the system running. It copies deletions, corruption and encryption to every disk instantly, so it is one copy of the data, not several.
What is the difference between a recovery time objective and a recovery point objective?
The recovery time objective is how long the organization can be down. The recovery point objective is how much data loss is acceptable, measured as time since the last backup. A nightly backup means a recovery point objective of one day.
Which data should the rule be applied to?
Everything whose loss would stop the business: the file server, the line of business database, virtual machine images, device configuration, certificates, and the cloud mailboxes. Anything left off the list is unprotected regardless of how well the rule is followed elsewhere.
Is a 3-2-1 backup strategy expensive?
Less than most people expect for a small organization, because the second copy is cloud object storage priced by what it holds. The cost that surprises people is the bandwidth and the time to restore, which is a recovery problem rather than a storage one.
What about the 4-3-2 rule?
Four copies, three locations, two offsite. It removes the shared dependency on a single offsite provider, and it is aimed at service providers and regulated environments rather than ordinary businesses.
Is the 3-2-1 rule the same as disaster recovery?
No. The 3-2-1 rule is about where copies of data live. Disaster recovery is the wider plan for bringing systems back after a fire, flood or ransomware attack: who does what, in which order, and how long it may take. A 3-2-1 backup is what makes that plan possible.
Keep readingRelated concepts
Read next · Identity and access What Is MFA? The backup account is the one an attacker wants most, which makes its authentication part of the backup design. Open this next16 min- Shared storage · 12 min NAS vs SAN The local backup target in most small networks is a NAS, and choosing one is a separate question from the rule.
- Disks and drives · 11 min RAID 5 vs RAID 10 RAID is redundancy inside one machine, which is the thing most often mistaken for a backup.
- Managed IT · 10 min What Is an MSP, and What Are You Actually Buying Who runs the copies when a business does not run them itself, and what a managed service provider contract covers besides.
- Managed IT · 10 min What Backup and Disaster Recovery Actually Buys You How the backups should be arranged.
- Managed IT · 11 min IT Outsourcing, and the Decision Behind It What the baseline should already cover before you sign.
- Backup · 12 min Immutable Backups, and the Setting That Decides Whether They Work The strategy this control was added to, and why it needed adding.
- Platforms · 11 min OneDrive vs SharePoint, and What Happens When Someone Leaves What actually protects the content in either place.
- Disks and drives · 9 min FAT32 vs NTFS, and Where exFAT Fits Which file system suits a backup disk, and why portable formats lose files on a bad unplug.
- Identification · 8 min Memory vs Storage, and Which One to Upgrade on a Slow PC Why nothing in memory is ever backed up, and how to size RAM and a drive for an office PC.