The 3-2-1 rule is the most quoted advice in backups: three copies of your data, on two different media, with one offsite.
It was written for a world of tape drives and a fireproof safe, and it is still mostly right. But two of its three clauses need translating before they mean anything to a team whose entire infrastructure is somebody else's computer.
Clause by clause
Three copies. Translates cleanly. Your production data plus two more. This one never needed updating.
Two different media. Meaningless as written. You do not have media. You have one object storage API, and choosing between two storage classes inside it is not what the original rule was protecting against. The intent behind "two media" was do not let one failure mode take both copies, and in a cloud stack the equivalent axis is not media, it is account and provider.
One offsite. This is the clause that survived intact, and it is the one most often faked. "Another region in the same account" is not offsite. The failure that takes a modern company's data is almost never geographic.
The translation
| Original | What it protected against | Cloud equivalent |
|---|---|---|
| Three copies | Any single copy being lost or corrupt | Production, plus two independent copies |
| Two media | One technology failing across both | Two accounts, ideally two providers |
| One offsite | The building burning down | One copy outside the blast radius of your primary credentials |
So the working version for a cloud-only stack:
Three copies, in two accounts, with one under credentials your production environment does not hold.
That last clause is the whole rule now. Everything else is commentary.
3
Copies
2
Accounts, not media
1
Set of credentials production cannot reach
Why the credential boundary replaced the physical one
The 1980s threat was fire, flood and theft, and geography was a good proxy for independence. Two buildings genuinely did not fail together.
Today the overwhelmingly common cause of total data loss is a compromised or
misused credential, and geography is no proxy at all. An access key with
s3:DeleteObject on your backup bucket has exactly the same reach whether that
bucket is in the next rack or the next continent. A Terraform state that manages
both regions destroys both regions with one command.
So the question to ask about each copy is not where it is. It is: which credentials can delete this, and does anything in production hold them?
If the answer is "the same key that runs my application", you have one copy wearing three hats.
A realistic 3-2-1 that people actually maintain
The version that survives contact with a small team:
- Production data. Copy one, free.
- Provider snapshots, automatic, inside the provider. Fast recovery for ordinary mistakes. Copy two, nearly free, and not independent.
- A portable dump in a bucket in a separate account, with Object Lock in governance mode and credentials that exist nowhere in production. Copy three, and the only one that satisfies the real rule.
Three copies. Two accounts. One outside the blast radius. It is achievable in an afternoon and it is dramatically better than what most teams have.
Where we fit
Copy three is the one we exist to make easy, and we make it deliberately independent: it lands in a bucket you own, under credentials we hold no copy of, encrypted before it leaves the machine that produced it.
We also do not need delete permission on your bucket and do not ask for it by default. If you never grant it, expired copies simply stay where they are and we cannot remove them. That is the correct default for a copy whose entire purpose is being outside everyone else's reach, including ours.
The one-line version
Three copies, two accounts, one set of credentials your production environment has never seen. If you get only the third clause right, you have most of the value of the rule.