The 3-2-1 backup rule, rewritten for SaaS

The 3-2-1 backup rule says: keep 3 copies of your data, on 2 different media types, with 1 copy offsite. It is the most repeated piece of backup advice in existence, and for Microsoft 365, Google Workspace, Slack and Atlassian Cloud it is wrong in a specific, fixable way. The rule was written for files you hold on media you own, and all three digits assume that. In SaaS you own no media, your data is already offsite, and the thing that destroys it is not a drive failing — it is an authorised account doing authorised things. The rule is still worth following. It just has to be translated from media into fate.

Where the rule comes from, and what it literally says

The 3-2-1 rule has a more official pedigree than most people realise. It appears verbatim in Data Backup Options, a paper by Paul Ruggiero and Matthew A. Heckathorn, copyright 2012 Carnegie Mellon University and produced for US-CERT:

Whatever backup options you choose, remember to follow the 3-2-1 rule of backups: 3 — Keep 3 copies of any important file: 1 primary and 2 backups. 2 — Keep the files on 2 different media types to protect against different types of hazards. 1 — Store 1 copy offsite (e.g., outside your home or business facility).

Two things in that text matter more than the numbers.

The first is the stated purpose of the "2": to protect against different types of hazards. The rule is a hedge against correlated failure. Two copies on two drives from the same batch fail together; a drive and a tape do not. That is the whole idea, and it survives the move to SaaS perfectly well.

The second is the parenthetical on the "1": outside your home or business facility. Offsite, in 2012, meant a different building, so that one fire or one flood could not take both copies. It is a geographic instruction because in 2012 the copies were physical objects.

The lineage runs back further, into professional photography rather than enterprise IT — the US-CERT paper's own Further Reading section points readers at the American Society of Media Photographers' Backup Overview for the rule. It is commonly credited to photographer Peter Krogh's 2005 book The DAM Book. That origin explains its shape: a photographer's negatives are irreplaceable, there is no vendor holding a second copy, and the enemy is a hard drive dying in a cupboard.

Why the 3-2-1 backup rule breaks on SaaS data

Run each digit against a Microsoft 365 tenant and watch it come apart.

"3 copies" — you already have far more than three, and they don't count. Microsoft documents that OneDrive, SharePoint and Exchange Online "have a proprietary architecture design for resiliency with replicated copies of customer data to failover to live active copies seamlessly without the need for end customer intervention." That is many copies, professionally managed. But replication is designed to survive hardware failure, and it works by faithfully reproducing whatever the live copy says. When ransomware encrypts a file, replication's job is to make sure every replica gets the encrypted version. A perfect copy of ruined data is ruined data. In 3-2-1's terms these are one copy, because they share one fate.

"2 different media types" — you own zero media. There is no second media type to choose, because you are not holding any. The closest honest translation is two different providers, and even that is easy to fake. Microsoft's own backup product is, by its documentation, "built on top of standard OneDrive and SharePoint infrastructure; and on top of standard Exchange Online infrastructure." It is a genuinely useful product with real recovery points, but it is not a second medium in the sense the rule means.

"1 copy offsite" — satisfied trivially, and uselessly. Your data is already in someone else's building. By the 2012 definition you cleared this bar the day you signed up. But the intent was independence, not distance — and here Microsoft is admirably direct about what its backup does: "Data never leaves the Microsoft 365 data trust boundary and honors the geographic locations of your current data residency."

Read that sentence twice. For EU data residency it is exactly what you want, and it is a legitimate selling point. For the "1" in 3-2-1 it is the opposite of the requirement. The copy is inside the same boundary, reachable by the same administrators, governed by the same tenant. Microsoft is equally clear that "the backups are immutable unless expressly deleted by the Backup tool admin via product offboarding" — with a 90-day grace period to recover them afterwards, which is a real and well-designed safety net, and also an admission that the delete path exists.

The translation: from media to fate

Keep the numbers, change what they count. The rule stops being about storage hardware and starts being about independent failure domains:

• 3 copies → 3 recovery paths that can fail independently. Live data, a native recovery mechanism, and a copy the platform does not control. Count distinct ways of getting your data back, not distinct bytes on disk.
• 2 media → 2 trust boundaries. The meaningful split in SaaS is not disk versus tape, it is who can authorise destruction. Two copies that answer to the same identity provider are one copy wearing two hats.
• 1 offsite → 1 copy outside the blast radius of a compromised administrator. Not a different country. A different control plane. This is the digit that does the actual work against ransomware, and it is the one native tooling is least likely to satisfy.

That third point is really a question about isolation, which we cover in more depth in what an air-gapped backup actually cuts, and about whether a copy can be altered at all, which is the subject of immutable backup and what the word really promises.

What the four platforms give you natively

Against the rewritten rule, native tooling scores better than vendors' critics claim and worse than the marketing implies:

• Microsoft 365 is the only one of the four with genuine point-in-time recovery points, and it publishes its restore expectations in detail — we worked through what those imply in RTO and RPO for SaaS workloads. It satisfies "3 recovery paths" and fails "1 outside the blast radius".
• Google Workspace gives administrators a short, all-or-nothing restore window rather than point-in-time recovery; every route to backing up Google Workspace covers what each one does and does not capture.
• Slack offers an export, which is a copy of data in a format you cannot restore from — see what a Slack export actually contains.
• Atlassian Cloud has deletion windows and manual exports rather than a restore path; the detail is in Atlassian Cloud backup and its native limits.

In every case the gap is the same one: the second and third copies, where they exist, live inside the boundary they are supposed to be insuring against.

The digit the original rule left out

A popular variant extends the formula with two more numbers — one copy offline or otherwise unalterable, and zero errors on verification. The first is a restatement of the isolation point above. The second is the genuinely missing instruction, because an untested backup is a belief, not a control.

This is not hypothetical. ENISA's Threat Landscape 2026 maps the techniques of the most active ransomware operators in the EU to MITRE ATT&CK, and T1490, "Inhibit System Recovery", is attributed to four of the five — Akira, Hunters International, Qilin and Safepay. Attacking the recovery mechanism before attacking the data is standard practice, not an exotic refinement. A backup you have never restored from is exactly the kind of control that fails quietly under that pressure.

A 3-2-1 check you can run this week

Ask five questions about one real workload:

1. How many ways can I get this data back, and would any two of them survive the same bad day?
2. Which identity can delete or re-scope every copy? If it is one identity, I have one copy.
3. If a copy is immutable, who can shorten the retention, and does that require anyone else's approval?
4. When did someone last perform a restore — not verify a job completed, but produce a usable file?
5. If the tenant itself were unavailable, which copy could I still read?

If the honest answers are "two", "yes, the global admin", "the global admin", "never" and "none", the 3-2-1 rule is not being met in any form that would help, regardless of how many replicas exist.

Working out which of those gaps actually matter for your tenants is what our free SaaS backup assessment is for: bring one workload, and we will map the recovery paths you already have, identify which of them share a fate, and help you choose and deploy a solution that closes the gap that is left.