A production database gets encrypted at 2 a.m. on a Saturday. The on-call engineer pulls up the backup console and finds exactly one copy — sitting on the same SAN the ransomware just finished sweeping. The backup job succeeded every night for six months. It just never protected anything, because a single copy on shared infrastructure was never a backup strategy to begin with.
This is the scenario the 3-2-1 backup rule was built to prevent, and it’s why the rule has outlived every specific technology it was originally written around. It predates cloud object storage, predates ransomware-as-a-service, and predates most of the tools practitioners use today. It is still the baseline every backup architecture gets measured against, because the failure modes it addresses — hardware failure, site loss, and correlated destruction — haven’t gone away. They’ve just gotten more automated on the attacker’s side.
This piece covers what the rule actually specifies, why each number in it exists, how it’s implemented in real on-prem-plus-cloud environments, where teams get it wrong, and how it extends into the 3-2-1-1-0 model that most current guidance now recommends.
What the 3-2-1 rule actually says
The rule is simple by design: keep 3 copies of your data, on 2 different types of media, with 1 copy stored offsite.
Breaking that down:
- 3 copies means the production data plus two backups — not three backups. If the primary copy is lost, you still have two independent fallbacks, which matters because backup jobs themselves fail silently often enough that a single backup copy is a coin flip, not a guarantee.
- 2 different media types means the two backup copies can’t both live on the same storage class. Disk-to-disk-to-disk within one array, one vendor, one failure domain doesn’t satisfy this — a firmware bug, a bad controller, or a single ransomware strain built to target that platform can take out both copies at once. Practical pairings: local disk plus cloud object storage, or local disk plus tape, or NAS plus a different cloud provider.
- 1 copy offsite means physically or logically separated from the primary site — a different building, a different region, a different provider account. This is the one that protects against fire, flood, theft, and regional outages, and it’s the one most frequently skipped by teams who back up religiously but only ever to a second array in the same rack.
CISA’s guidance to businesses states this almost verbatim: keep three copies of important files, on two different media types, with one stored offsite, as a foundational control against both hardware failure and malware (CISA, Back Up Business Data). NIST’s contingency planning guidance covers the same territory in more formal terms, describing backup storage location, media rotation, and geographic separation as core elements of an information system contingency plan (NIST SP 800-34 Rev. 1).
Why the rule exists: it’s about failure domains, not copy counts
The number 3 isn’t magic. What matters is that each copy sits in a genuinely independent failure domain, so that no single event — a bad patch, a compromised admin account, a fire, a ransomware payload with lateral movement — can take out more than one copy at a time.
Think through the failure classes the rule is designed against:
- Hardware failure. Drives fail, controllers corrupt, RAID arrays degrade past their fault tolerance. A second copy on different physical media catches this.
- Site-level disaster. Fire, flood, theft, or a data center outage takes out everything in one location at once. The offsite copy catches this.
- Malicious deletion or encryption. An attacker (or a disgruntled insider) with access to production also has access to anything reachable from production. If your “backup” is just a mounted network share, it’s reachable, and it’s gone the moment the primary is.
- Operational error. Someone runs a destructive script against the wrong environment. Having a copy that wasn’t in the blast radius of that action is what makes it recoverable.
The rule works because it forces you to ask, for each copy: what single event destroys this and the other copies simultaneously? If you can’t answer “nothing plausible,” the architecture doesn’t actually satisfy 3-2-1, whatever the copy count says on paper.
Practical on-prem + cloud implementations
Most current environments implement 3-2-1 as some combination of local performance-tier storage and cloud durability, rather than the tape-heavy setups the rule originated in. A few patterns that hold up in practice:
Local disk + cloud object storage. Primary backups land on local disk or a backup appliance for fast restores, then replicate to an S3-compatible bucket (AWS S3, Backblaze B2, Wasabi, or similar) in a separate account from production. This satisfies media-type separation (disk vs. object storage) and offsite (different provider, different region) in one architecture. Veeam-class platforms, as well as open-source options like Restic or Borg backup targeting a cloud repository, all fit this pattern.
Rsync or Borg to a remote host. For smaller environments or Linux-heavy shops, a nightly rsync or Borg job to a physically separate machine — a colo box, a relative’s spare server, a cheap VPS with attached storage — satisfies offsite and, if that target uses different underlying storage (say, a different disk type or a hosted block volume), satisfies media diversity too. This is lower-cost and more hands-on than a managed platform, but it’s a legitimate 3-2-1 implementation when configured correctly.
Cross-cloud replication. Organizations already running production in one cloud sometimes replicate backups to a second cloud provider rather than a second region of the same provider, on the theory that a billing dispute, account compromise, or provider-side outage affecting one platform shouldn’t also take out the backup. This is a defensible read of “different media type” at the platform level, though it adds operational overhead that not every team can sustain.
Traditional tape. Tape isn’t dead in regulated and high-volume environments. Its air-gapped-by-default nature (a tape not currently in a drive is physically disconnected) makes it a strong offline copy, and it remains one of the cheapest options per terabyte for long-term retention. The tradeoff is restore speed — tape is not the tier you want for an RTO measured in minutes.
None of these require a specific vendor. What they have in common is that the failure domains genuinely don’t overlap.
The 3-2-1-1-0 extension
Ransomware changed the threat model the original rule was written for. Attackers now specifically target backup infrastructure — deleting snapshots, encrypting backup repositories, and disabling replication jobs before triggering the encryption payload on production, precisely because they know a clean backup makes the ransom irrelevant. CISA’s #StopRansomware Guide is explicit about this: many ransomware variants search for and destroy accessible backups as a core part of the attack, which is why offline and immutable backup copies are now treated as a baseline control rather than an enhancement (CISA, #StopRansomware Guide).
That’s the origin of 3-2-1-1-0:
- 3 copies, 2 media types, 1 offsite — unchanged from the original rule.
- 1 copy offline, air-gapped, or immutable — a copy the attacker cannot reach, modify, or delete even with full administrative credentials on the production network. This can mean a genuinely disconnected tape, a backup vault with no standing network path, or object storage with immutability enabled (S3 Object Lock in compliance mode, for instance) so that even a compromised account with delete permissions can’t remove data inside its retention window.
- 0 errors after restore verification — a backup is not “done” when the job reports success. It’s done when a restore has actually been tested and the recovered data verified against the source. A backup job with a green checkmark and an untested restore path is a liability dressed up as a control.
The “0” is the element most teams skip, and it’s arguably the most important one. Backup jobs report success based on whether data was written, not whether it’s recoverable — corruption, incomplete application-consistent snapshots, and silent schema drift between backup and restore environment all pass a “successful” backup job and then fail at the worst possible moment. Scheduled restore testing, ideally automated and run against a subset of critical systems on a recurring cadence, is what actually closes that gap.
Common mistakes
A few patterns show up repeatedly in post-incident reviews:
- Counting snapshots as backups. A storage-array snapshot is fast and useful, but it typically lives on the same underlying storage as production. It protects against logical error (a bad deploy, an accidental delete) but not against the array itself failing or being encrypted. Snapshots are a complement to 3-2-1, not a substitute for it.
- Two copies, one media type, called “3-2-1” anyway. Two backup jobs pointed at two different NAS boxes from the same vendor, in the same building, is not offsite and arguably not media-diverse either. This is the single most common gap found during backup architecture reviews.
- No restore testing. Covered above, but worth repeating: an untested backup is a hypothesis, not a recovery capability.
- Backup credentials that mirror production access. If the same domain admin account that runs production also has full delete rights on the backup repository, the “separate” copy isn’t actually separate from an attacker’s perspective. Backup infrastructure should use credentials that are isolated from, and ideally more restricted than, production admin access.
- Treating RAID as backup. RAID protects against a single drive failure; it does nothing against deletion, encryption, site loss, or a bad write propagating across the array. It belongs in the availability conversation, not the backup one — see our companion piece on why RAID is not a backup for the full breakdown.
How 3-2-1 interacts with RPO and RTO
3-2-1 tells you where your copies live and how many there are. It doesn’t, by itself, tell you how much data you can afford to lose or how fast you need to be back online — that’s the job of Recovery Point Objective (RPO) and Recovery Time Objective (RTO), and the two frameworks have to be designed together.
Backup frequency has to satisfy your RPO: if the business can tolerate losing at most 15 minutes of transactions, nightly backups don’t meet that requirement regardless of how well they satisfy 3-2-1 — you need continuous replication or frequent incremental snapshots feeding into the 3-2-1 architecture, not just a schedule change. Conversely, the media and location choices in 3-2-1 have to satisfy your RTO: an offsite copy on tape sitting in a vault three hours away might satisfy the “offsite” requirement perfectly while making a four-hour recovery time objective impossible to hit, because retrieval and restore-from-tape simply take longer than that.
The practical approach is to set RPO and RTO per system tier first — critical systems get tighter targets, archival systems get looser ones — and then design the 3-2-1-1-0 implementation backward from those numbers, rather than applying one backup architecture uniformly across systems with very different recovery needs. For a deeper treatment of how these targets get set and traded off against cost, see our dedicated piece on RPO vs. RTO.
Frequently Asked Questions
Is the 3-2-1 backup rule still relevant with cloud backup?
Yes. Cloud backup doesn’t replace the rule, it changes how you satisfy it. A single cloud copy is still one copy in one failure domain — account compromise, billing disputes, or a misconfigured lifecycle policy can wipe it out. Combining local backup with a cloud copy in a separate account, or two clouds, still requires deliberate design to hit genuine media and location diversity.
What counts as a separate media type?
Media type refers to fundamentally different storage technology and failure characteristics, not just different devices. Local disk plus cloud object storage counts; local disk plus a second local disk array from the same vendor generally doesn’t, since both fail the same way under firmware bugs or coordinated attacks. Disk, tape, and cloud object storage are the three practical categories most architectures mix between.
How does 3-2-1-1-0 differ from 3-2-1?
3-2-1-1-0 adds two requirements on top of the original three: one copy must be offline, air-gapped, or immutable so ransomware with full network access still can’t destroy it, and restores must be tested to zero errors before a backup counts as reliable. It’s the same core rule adapted for a threat model where attackers actively target backup infrastructure, not just production.
Does 3-2-1 apply to SaaS data like Microsoft 365 or Google Workspace?
Yes, and it’s frequently skipped because teams assume the SaaS provider’s own redundancy covers it. Provider redundancy protects against the provider’s infrastructure failing; it does not protect against account compromise, accidental deletion, or a malicious insider purging mailboxes and files, which the provider’s retention window may not fully cover. See our guide on Microsoft 365 backup for how 3-2-1 principles apply to SaaS-hosted data specifically.
How often should restore testing happen to satisfy the “0” in 3-2-1-1-0?
Frequency should scale with how critical the system is and how often its backup configuration changes — quarterly at minimum for critical systems, with automated, sampled restore verification running more often where tooling allows. The specific cadence matters less than it actually happening on a fixed schedule rather than only after an incident, when it’s too late to fix a broken restore path.