Three copies, two media types, one offsite has guided backup design for two decades. The 3-2-1 backup rule still holds, but a literal reading of it can leave a cloud estate one bad credential away from losing everything.
What is the 3-2-1 backup rule?
The 3-2-1 backup rule is a data protection strategy that keeps three copies of your data, stored on two different types of media, with one copy kept offsite.
Each number does a specific job:
- 3 means three copies: your live production data plus two backups, so a second backup still stands when the first turns out unreadable or is hit by the same event.
- 2 means storing copies on two different footings, originally distinct media like disk and tape, so one failing technology cannot take down more than one copy.
- 1 means keeping at least one copy offsite, physically separate from the other two, which for cloud-first teams usually means another region or a locked-down account rather than a building across town.
Where did it come from?
The 3-2-1 backup rule comes from photographer Peter Krogh, who described it in his 2005 book The DAM Book: Digital Asset Management for Photographers. He was solving a personal problem, which was how to keep decades of irreplaceable image files safe from drive failure and disaster.
The framework spread far past photography because the logic is technology-agnostic. You can apply it to a laptop, a server rack, or a multi-region cloud estate without changing a word.
That portability is why the United States government adopted it. CISA recommends the 3-2-1 rule as a baseline for protecting business data, and the principle lines up with the NIST Cybersecurity Framework control for creating, protecting, and testing backups.
How the 3-2-1 backup rule works in practice
The 3-2-1 backup rule works by spreading copies across independent points of failure, so no single event wipes out all of them. The clearest way to see it is a real cloud workload rather than a photo on a laptop.
Picture a production PostgreSQL database running in one AWS account. That is copy one. An automated backup writes to separate storage that production cannot overwrite, which is copy two on a different footing from the source. A third copy lands in another region or a separate, locked-down account, which satisfies the offsite requirement.
Retention is where the offsite copy earns its keep. For example, SoFi runs across five AWS regions, and its team needed retention changes on student-loan workloads to apply in seconds rather than waiting hours or days for manual work across regions.
When the rule is set up well, recovery comes down to finding the right copy and restoring the exact data the incident touched.
Why the 3-2-1 backup rule still matters
The 3-2-1 backup rule still matters because it removes single points of failure, which remains the most common reason a recovery falls apart. A backup that sits next to production, on the same hardware or in the same account, is one bad event away from being useless. The rule forces separation by design.
It also gives teams a shared language. When CISA, NIST, and every major vendor describe backup design, they start from the same three numbers. That consistency makes the rule a reliable floor to build on, and a fast way to spot an obvious gap.
If you cannot point to three copies, two footings, and one offsite location, you have found a weakness before an incident does.
The rule is a starting point, though, not a finish line. The assumptions behind it were written for a world of drives and tape, and two of them strain once everything moves to the cloud.
Where the 3-2-1 backup rule falls short in the cloud
The 3-2-1 backup rule falls short in the cloud when all three copies live in one provider, reachable by the same credentials, and restored the same slow way. The pattern is still sound, but a literal reading of it can leave a cloud estate exposed in three ways.
Three copies, one blast radius
Three copies only help if something cannot destroy all of them together. In the cloud, the thing that reaches every copy is usually a credential. When the same IAM role can read production and write to the backup store, a compromised or buggy process can take out the whole chain.
Attackers know backups are the recovery plan, so they go after them first. In ransomware incidents studied by Sophos, 94% of victims said attackers tried to compromise their backups, and 57% of those attempts succeeded.
Eon's 2026 report documents an AI coding agent that deleted a company's production database and its volume-level backups in nine seconds, after resolving a staging error by calling delete on production storage. Three copies behind one set of permissions is one copy with extra steps.
A logically air-gapped, immutable vault keeps the offsite copy unreachable from the credentials that run production, so a single compromise cannot cascade.
Media diversity barely exists in object storage
Two different media types made sense when the options were tape, optical, and spinning disk. In a cloud-native estate, almost everything is object storage sitting on the same underlying infrastructure.
Copying an S3 bucket to another S3 bucket technically gives you two copies, but it does not give you the independent failure footing the original rule intended.
The cloud version of media diversity is logical isolation. Separate accounts, separate credentials, and immutability deliver the independence that two physical media types used to provide.
A copy is not a recovery
Having three copies says nothing about how fast you can restore the one record you actually need. This is where the rule is silent and where teams get hurt. Per Eon's 2026 report, 60% of respondents need six or more hours to complete a full restore, and only 5% can do it in under an hour.
Slow recovery usually comes from restore designs that force you to rehydrate an entire environment just to pull back a single row. Granular restoration matches the unit of recovery to the unit of damage, so a file, object, table, or customer record comes back in minutes without spinning up everything around it.
Modern cloud-native platforms like Eon carry the same goal further, applying immutability by default, isolating copies by credential rather than by media type, recovering at the record level in minutes, and providing coverage automatically as the environment changes.
The three numbers still describe where to start, and a platform built for the cloud is what closes the distance between holding backups and actually recovering from them.
What comes after 3-2-1: 3-2-1-1-0 and 4-3-2
3-2-1-1-0 and 4-3-2 rules add immutability, verification, and extra offsite redundancy for ransomware-era threats. Both build on 3-2-1.
The 3-2-1-1-0 backup rule
The 3-2-1-1-0 backup rule keeps the original three numbers and adds two more. The extra 1 is one immutable or logically air-gapped copy that cannot be altered or deleted for a set period, which blocks attackers and runaway processes from destroying backups.
0 means zero errors, confirmed by regular testing that restores actually work. This is the model most cloud and enterprise teams move to once ransomware enters the threat picture.
The 4-3-2 backup rule
The 4-3-2 backup rule pushes redundancy further with four copies, across three locations, and two of them offsite. It suits organizations that need high availability and fast failover across regions, and that accept the added cost and operational load.
For most teams, it is more than the situation calls for, but it is a sensible target for the most critical workloads.
What all these rules still miss
What every version of the 3-2-1 rule misses is visibility: you cannot apply any of these patterns to resources you cannot see. A rule can tell you how many copies to keep and where to put them, but not whether last week's new database or storage bucket was ever picked up in the first place.
In a cloud estate that changes daily, that blind spot is where protection quietly lapses. Eon also found that 61% of teams discover protection gaps only after an incident, audit, or failed restore, which is the most expensive time to learn a workload was never covered.
Cloud Backup Posture Management (CBPM) closes that gap by classifying new resources as they are created and applying retention and protection policy automatically, so coverage keeps pace with the environment instead of trailing behind it.
Putting 3-2-1 to work in the cloud
The 3-2-1 rule still applies in the cloud; what changes is how you satisfy it. The three numbers stay, but the work shifts from counting copies and media types to isolation, coverage, and verification, which is where modern cloud backup best practices now focus. Four moves carry it across:
- Keep one copy logically air-gapped. Put at least one backup in a separate account with its own credentials and immutability, so a compromised production role cannot reach it. Isolation like this is the backbone of any ransomware backup strategy.
- Prove coverage continuously. Track what is and is not protected across accounts, regions, and the multi-cloud estates most teams now run, instead of assuming new resources were picked up.
- Test granular restores, not just full ones. Confirm you can bring back a single file, record, or table quickly, because that is what most incidents actually demand.
- Verify on a schedule. Run restore tests often enough to earn the 0 in 3-2-1-1-0, because an untested backup is only a guess.
When was the last time you restored a single record, timed it, and liked the answer? If you’re not sure your cloud backups would survive that test, book a demo and see how Eon handles isolation, coverage, and granular recovery.
Frequently asked questions
Is the 3-2-1 backup rule still relevant in 2026?
Yes, the 3-2-1 backup rule is still relevant in 2026 as a baseline. CISA and NIST continue to endorse it, and it remains the starting point most vendors use to describe backup design. Cloud and enterprise teams now extend it to 3-2-1-1-0 to handle ransomware that targets backups directly.
What is the difference between 3-2-1 and 3-2-1-1-0?
The main difference between 3-2-1 and 3-2-1-1-0 is two added requirements. The 3-2-1-1-0 rule keeps three copies, two media types, and one offsite copy, then adds one immutable or logically air-gapped copy and zero verified restore errors. Those additions defend against attackers who go after backup infrastructure.
Does cloud storage count as the offsite copy in the 3-2-1 rule?
Yes, cloud storage counts as the offsite copy when it is genuinely separate from your primary data. A cloud copy that syncs directly from production, or that shares credentials with it, does not provide real separation. The offsite copy should be independently recoverable even if primary systems are compromised.
Who created the 3-2-1 backup rule?
Photographer Peter Krogh created the 3-2-1 backup rule, describing it in his 2005 book The DAM Book: Digital Asset Management for Photographers. He framed it to protect irreplaceable image files, and the IT industry adopted it because the logic applies to any kind of data.
Is one cloud backup enough to protect my data?
No, one cloud backup is not enough on its own. A single copy leaves you exposed to deletion, corruption, ransomware, and credential compromise that can reach it. Keeping three copies with one isolated and immutable, then testing restores, is what makes recovery dependable.
