What Is the 3-2-1 Backup Rule?

Three copies is about independent failure. One copy is a single point of loss. Two copies protect against the ordinary case in which one of them fails, but they also share a fate whenever the failure is correlated — the same controller, the same rack, the same script, the same mistake. The third copy exists so that a single event, including the event of a backup itself being silently corrupt, does not take the last remaining version with it. It is worth counting honestly here: a RAID array is not two copies, because RAID protects against a failed drive rather than against deletion, corruption, or ransomware, all of which write to every member at once.

Two media types is about correlated defects. Identical devices bought together fail in similar ways at similar times — the same firmware bug, the same manufacturing batch, the same wear pattern under the same workload. Different media break the correlation. Historically that meant disk and tape; today it just as often means production flash, a disk-based backup appliance, and object storage on a different platform entirely. The test is not whether the two things look different in a diagram but whether a defect in one has any plausible way of affecting the other.

One copy off-site is about the building. Fire, flood, theft, prolonged power loss, and physical destruction do not respect how well organized the rack is. Off-site means a genuinely separate failure domain, far enough away that a single physical event cannot reach both. This is also the number that quietly changed meaning when backup moved to the cloud, which is worth its own passage.

The usual objection to the rule is that the media distinction is obsolete now that production, backup, and cloud storage are all ultimately flash or spinning disk. That reading is too literal. What the second number defends against is a shared failure mode, and shared failure modes today are less often about the physical medium than about the platform, the vendor, the firmware, the management plane, and the credentials. Two arrays of the same model, administered from the same console with the same account, are one medium for every purpose that matters.

Read that way, the rule remains straightforward to satisfy. A backup appliance from a different vendor than the production array, object storage on a different platform, and tape all count as a second type; a replica of production onto identical hardware managed by the same team with the same credentials does not, whatever the storage layer underneath. Tape retains one property nothing else has, which is that a written cartridge leaves the drive entirely and has no network interface at all — the reason it keeps reappearing in resilience designs long after it was declared finished.

Cloud backup satisfies the off-site requirement geographically, and geography was never the whole point. A copy replicated into the same cloud account, reachable by the same identity provider, administered by the same credentials as production, is in a different building and the same failure domain. The events the third copy exists for now include credential compromise and account-level destruction, and against those, distance contributes nothing.

The useful question is what a copy is independent of. A separate physical site is independent of a fire. A separate cloud account or tenant with separate credentials is independent of an identity compromise. Offline or removable media is independent of anything that requires a network path. Most organizations discover, when they write this out, that their three copies are independent along one axis and identical along another — usually all reachable from one directory service — and that fixing it is a permissions and architecture change rather than a purchase.

Two gaps have opened since 2005, and both were exposed by ransomware. The rule says nothing about whether a copy can be deleted — an attacker with administrative credentials can satisfy all three numbers and then remove all three copies in an afternoon, which is a routine part of how these intrusions are run. And it says nothing about whether a copy works: an unverified backup is a hypothesis, and the discovery that a restore fails, or takes days against an eight-hour objective, tends to happen exactly once, at the worst possible moment.

A widely circulated extension addresses both by adding two more digits: 3-2-1-1-0. The fourth digit calls for one copy to be offline, air-gapped, or immutable — a copy the credentials that administer everything else cannot destroy. The fifth calls for zero errors, meaning recovery verification is performed and passes rather than being assumed. Neither is a new idea, and both are what CISA's ransomware guidance has been saying in plain language for years: maintain offline, encrypted backups, and regularly test their availability and integrity, because ransomware variants actively hunt for and delete any backups they can reach.

For federal systems, the document that actually governs this territory is NIST SP 800-34 Revision 1, the Contingency Planning Guide for Federal Information Systems. It does not use the phrase 3-2-1 and should not be cited as if it did. What it requires is the substance the shorthand is a mnemonic for: a business impact analysis that establishes which systems matter and in what order, recovery time and recovery point objectives derived from that analysis rather than chosen by preference, a documented backup strategy proportionate to the system's impact level, alternate storage and processing site selection with explicit criteria including distance from the primary site, and testing and exercises to prove the plan works.

That is the more useful frame for anyone writing a requirement. 3-2-1 tells you the shape of a defensible design in six words, which is why it survives; SP 800-34 tells you how to justify the specific numbers for your environment, which is what an auditor asks for. Recovery objectives are the hinge between them. An RPO of fifteen minutes and an RPO of twenty-four hours produce entirely different architectures at identical copy counts, and the copy count is the cheap part of the decision.

Once the copies are decided, the hardware follows fairly directly. Copy one is production. Copy two is normally an on-premises backup target sized for the retention window and the change rate — a NAS or a purpose-built backup appliance, on different hardware from the production array and, where possible, under different credentials. Copy three leaves the site, as object storage on a separate platform, as tape written and rotated offsite, or both. Where 3-2-1-1-0 is being followed, the offline or immutable copy is usually a retention lock on the object tier or the tape leg rather than a fourth device.

Two costs get missed in this exercise with some regularity. Capacity is not the copy multiplied by three, because deduplication, compression, and different retention windows apply to each tier differently, and locked retention on an immutable tier cannot be relieved by deleting things when the repository fills. And restore testing needs somewhere to restore to — spare capacity, or a target environment that exists for the purpose — which is a line item that gets cut precisely because it is not the backup itself. The practical move at quote time is to send the design rather than the drive count: three copies, their media, their retention, and the recovery objectives they exist to meet. That is what turns a capacity number into a bill of materials that survives contact with the restore.