The 3-2-1 Backup Rule, Actually Implemented
The rule everyone quotes and almost nobody builds properly
Contents
Everyone can recite the 3-2-1 rule. Three copies of your data, on two different types of media, with one copy offsite. It gets quoted in every backup thread as if saying the words were the same as doing the work. Then you look at what people have actually built and it is a single NAS with RAID, which is one copy on one medium in one building — a long way from 3-2-1, and exactly the setup that loses everything to a house fire, a power surge, a theft or a rm run with too much confidence. The rule is sound. The gap is that “implement 3-2-1” is treated as a slogan rather than a concrete build, so this article is the build.
I am going to take the rule apart, explain why each number is the number it is, and then map the whole thing onto real tools running on real hardware, with the automation that keeps it alive and the failure modes that quietly break it. By the end you should be able to look at your own setup and say precisely which copy is which, or notice honestly that you are missing one.
Why three, why two, why one
The three numbers each defend against a different class of disaster, and understanding the “why” stops you from building something that technically counts but protects against nothing.
Three copies exists because copies fail independently only if there are enough of them. Your live data is copy one. If your only backup is copy two and you are mid-restore when you discover it is corrupt, you have nothing. A third copy demotes a single bad copy to an inconvenience you can shrug off. The number three is chosen so that any one copy can be lost or found faulty and you are still protected.
Two media types exists because failures correlate within a technology. Two hard drives from the same batch, in the same enclosure, on the same power supply, running the same firmware, tend to fail for the same reasons at the same time — a power surge, a firmware bug, a controller fault. Spreading copies across genuinely different media (spinning disk and cloud object storage, or disk and a different disk technology in a different machine) breaks that correlation so one media-class failure cannot take every copy at once.
One offsite exists because location is a single point of failure that no amount of on-site redundancy addresses. Fire, flood, theft, a lightning strike on the mains, or ransomware that reaches every machine on the LAN will destroy everything in one building regardless of how many copies are in it. The offsite copy is the one that survives the loss of the whole site, and it is the copy people most often skip because it is the most effort.
Notice what the rule does not say. It does not say “RAID counts as copies” — RAID is redundancy within a single copy, so a mirrored NAS is still one copy for 3-2-1 purposes. It does not say snapshots are backups; a snapshot on the same pool dies with the pool. Those two misreadings are why so many “3-2-1” setups are really 1-1-0.
A newer formulation you will see quoted extends the rule to 3-2-1-1-0: the extra 1 is one copy kept offline or air-gapped (immutable object-lock storage counts here), and the 0 means zero errors after a verification pass. Both additions target the same weakness the original three numbers leave open. A copy an attacker or a silent corruption can reach across the network is worth less than one that is genuinely unreachable and proven readable. You do not need to memorise the longer acronym to benefit from it — you need an offsite copy that something cannot quietly delete, and a standing habit of confirming it still restores.
A concrete build
Here is a setup that genuinely satisfies the rule, mapped to specific roles. Adapt the tools; keep the shape.
- Copy 1 — production. Your live data, on your main machine or NAS. On a ZFS or RAID pool this copy is internally redundant, which protects the copy against a dead disk but does not make it more than one copy.
- Copy 2 — local backup, different medium. A second machine or a dedicated backup disk that pulls from production nightly. Different disks, different power, ideally a different technology. Fast to restore from because it is on the LAN.
- Copy 3 — offsite. An encrypted copy in a location the fire cannot reach: a cloud object store, a friend’s server, or a small box at a relative’s house. Reached over the internet, encrypted client-side, and the one that survives losing the whole building.
That is three copies, across at least two media types, with one offsite. Every backup thread quotes the rule; this is what it looks like once it is real.
Mapping the copies to tools
The local backup (copy 2) wants to be fast and cheap to make. If production is on ZFS, the natural tool is ZFS send/receive, replicating snapshots block-by-block to a second pool on another machine — incremental, quick, and preserving the whole snapshot history. If you are not on ZFS, a Restic or Borg repository on a second disk does the same job with encryption and deduplication.
The offsite copy (copy 3) wants to be encrypted and to work over an unreliable domestic uplink. This is where Restic and Rclone to storage you don’t fully trust fits exactly — client-side encryption means the remote provider stores only ciphertext, and Rclone lets you point the copy at whatever offsite target is cheapest, whether that is a cloud bucket or a self-hosted MinIO at a relative’s house.
A worked skeleton for the two backup legs, run on the backup host:
| |
Two commands, two copies, two very different failure domains. The local leg replicates a snapshot to a second box; the offsite leg encrypts and ships the same data to a remote that never sees plaintext.
Automating the whole thing
A 3-2-1 setup that depends on you remembering to run it is a 3-2-1 setup that degrades to 1-0-0 the first busy week. Drive both legs from systemd timers so they run untouched:
| |
Point the matching .service at the script above with Type=oneshot, enable with systemctl enable --now backup-321.timer, and confirm with systemctl list-timers that the next run is genuinely scheduled. Add one thing people forget: monitoring. A backup that has silently failed for three weeks is worse than no backup, because you think you are protected. Have the script ping a dead-man’s-switch service (a healthchecks-style URL) on success, so an absence of pings alerts you. A short weekly summary of what ran and how much data moved is a cheap second signal, and it trains your eye to notice when a number looks wrong before the gap becomes a disaster. Silent failure is the way most home backup schemes actually die.
Verifying you really have three copies
It is worth periodically proving the rule holds rather than assuming it. Walk the copies deliberately:
- Count the copies of one representative file. Production, local backup, offsite. If you cannot point at three, you do not have three.
- Check they are on different media. If “copy 2” and “copy 3” are two folders on the same physical disk, you have one medium and one copy dressed up as two.
- Confirm the offsite copy is genuinely offsite. A backup disk that sits on top of the NAS burns in the same fire, so it fails the offsite test outright.
The most important verification is that copy 3 restores. A backup you have never restored is a guess, and the discipline of proving it works deserves its own attention, covered in testing the restore you never rehearsed. Until you have pulled real data back out of the offsite copy, treat it as unproven.
Troubleshooting: how 3-2-1 quietly breaks
Both backups run from the same source at the same time and both inherit the same corruption. If production silently corrupts a file and both backup legs copy it before anyone notices, all three copies are bad. Retention with history is the defence — keep enough daily/weekly/monthly snapshots that an older, good version still exists after the corruption is discovered. Depth of history is part of the rule’s spirit even though it is not in the name.
The offsite copy shares a fate with production. An offsite backup reachable with the same credentials and deletable by the same compromised host is offsite in geography but not in failure domain. Ransomware that owns your main box can wipe a naively-configured offsite repo too. Use provider immutability (object lock / WORM) or append-only access so the offsite copy cannot be deleted by the machine being backed up.
“Two media” is really one. Two external USB disks of the same model, bought together, are one medium and correlate hard. Make copy 2 and copy 3 genuinely different: disk plus cloud, or disk plus a different machine in a different place. The point of two media is broken correlation, and identical hardware defeats it.
RAID is being counted as a copy. It is not. A mirrored or parity pool is copy one with internal redundancy. If your “three copies” are really one RAID pool plus a snapshot on that same pool plus a hopeful assumption, you have one copy. The mirrors-versus-parity decision affects how robust that single copy is, and nothing about how many copies you have.
The backup filled up and started skipping files. A backup target that runs out of space fails partially and often quietly. Monitor free space on both backup legs and set retention aggressively enough that the repositories stay bounded, so a full disk alerts you rather than silently dropping the newest data.
Verdict: is it worth it, and for whom?
If you have any data whose loss would genuinely hurt — photos, documents, a homelab you have poured years into — then yes, and 3-2-1 is the minimum bar rather than a gold standard. The rule is quoted so often precisely because it is right; the work is turning the slogan into three named copies on two real media with one genuinely offsite, automated so it survives your inattention and monitored so its silent failure reaches you.
It is more than a single tidy laptop with a couple of important folders strictly needs — for that, one good offsite backup plus the local original is a defensible two-copy compromise. Where the full rule earns its keep is anywhere you are the custodian of data other people also depend on, or where re-creating the data is impossible. Build the three copies, prove the offsite one restores, wire a dead-man’s-switch to the automation, and you will have the boring, unglamorous setup that quietly means a fire or a fat-fingered command is an annoyance instead of the day you lost everything.
Related Content
