The 3-2-1 backup rule, explained properly

Where the three numbers come from

The rule is usually credited to commercial photographer Peter Krogh, who popularized it in the mid-2000s for photographers sitting on irreplaceable RAW files with no IT department behind them. It spread because it's arithmetic, not opinion: each number defends against a cluster of failures the others don't touch. It generalized well past photography because the failure clusters — a bad disk, a compromised account, a burning building — are universal.

Three copies — because two is a coincidence

One production copy plus one backup means exactly one thing stands between you and total loss the moment that backup fails silently — bit rot, a corrupted incremental chain, a tape nobody checked in a year. A third independent copy is what turns "a backup exists" into "redundancy exists." Two copies is a coincidence; three is a policy.

Two different media or systems — because one fault shouldn't remove two copies

If your second and third copies live on the same disk, the same RAID array, or under the same cloud login, one fault removes more than one copy at once: a failing controller, a compromised credential, a provider-side outage. "Different media" means physically or logically distinct — local disk plus object storage, a laptop plus a managed vault — not two folders on the same server pretending to be independent.

One copy off-site, at a different provider — because sites and accounts fail as a unit

A fire, flood, or theft takes every on-premises copy at the same moment, no matter how many drives held them. The same logic applies to accounts: one hosting login can be suspended over a billing dispute, flagged by a ToS system, or compromised — and every bucket sitting inside that one account goes down together. A different region of the same provider still shares one account, one bill, one outage; "off-site" has to mean a different provider to actually count.

What people get wrong about 3-2-1

These four show up in almost every backup audit we run, usually presented with total confidence.

• RAIDKeeps a server running through a single disk failure. It does nothing against deletion, ransomware encrypting the whole array, a controller fault, or a fire — the event that destroys production destroys every disk in a local array at once. RAID is uptime, not backup.
• syncDropbox, Nextcloud, or OneDrive sync propagates a delete — or a ransomware encryption pass — to every synced copy within seconds. Sync exists to keep copies identical; a backup exists to keep them different across time.
• same accountTwo buckets in the same cloud account, under the same login, are one media type in practice. Whoever or whatever compromises the account gets both at once — that's not the "two" or the "one" in 3-2-1.
• snapshotA storage snapshot inside the same array or the same provider is genuinely useful for fast rollback, but it's still the "two" and the "one" you owe elsewhere — not a substitute for either.

The rule only works if you test the restore

3-2-1 describes where your copies live. It says nothing about whether any of them actually work when you need them — that's a separate discipline, and it's the one people skip. Two numbers decide how bad a real incident is:

RPO (Recovery Point Objective) is how much data you can afford to lose, measured backward from the failure — it's set by how often you back up. RTO (Recovery Time Objective) is how long it takes to get back to a working state — it's set by how well-rehearsed your restore actually is, not by how good your backup software's marketing page looks.

A restore you have never run is a rumour with a cron job, not a backup. Test monthly for anything that would hurt if it took a week to rebuild, and quarterly at minimum for everything else — on a calendar, not on faith.

Ransomware turns "the one" into "the one that must be unreachable"

Modern ransomware doesn't stop at production. It looks on the compromised host for backup credentials and, if it finds them, deletes or encrypts what they can reach — including your off-site copy, if that copy trusts the same key. An append-only (or immutable) repository accepts new snapshots during a locked retention window but the credentials sitting on production cannot delete or overwrite what's already stored there; a separate, more privileged key handles pruning, and it never touches the compromised host. That's the actual difference between ransomware encrypting your data, and ransomware encrypting your data and your backups.

Is 3-2-1 still enough in 2026?

A newer variant, 3-2-1-1-0, adds two more digits worth knowing: one copy that's offline or air-gapped (unreachable from any network at all, closing the gap append-only alone doesn't — physical removal, not just a locked write window), and zero errors after a verification pass on every backup. Neither replaces 3-2-1; both just make its weakest link — an untested, always-online "off-site" copy — explicit instead of assumed. If your off-site copy is append-only and gets restored on a schedule, you already cover most of what 3-2-1-1-0 is asking for.

A 3-2-1 setup, concretely

One production copy, one local-but-separate-media copy, one off-site append-only copy. In practice, that's often: the live data on the server (copy one); a same-site Borg or Restic repository on separate storage, or an rsync mirror with hardlinked daily snapshots (copy two); and an append-only repository at a different provider, reached over SSH or S3-compatible object storage (copy three).

Both commands are one line in a nightly cron job. The part that actually needs discipline is the restore test, not the backup job — the backup job runs whether you watch it or not.

What the "one" costs, in practice

Off-site storage priced per TB, net, as it stood in July 2026:

Own prices net, excl. VAT; pay annually and save 20%. Third-party prices as researched in July 2026 and normalized to €/TB or $/TB per month for comparison — always confirm current pricing on the provider's own page before deciding.

Frequently asked