Tukuk-OSThe Rule and the Arithmetic Behind It
The rule, hammered out by decades of sysadmins comparing post-mortems, is compact: keep three copies of anything you cannot afford to lose, on two different kinds of storage, with one copy kept offsite — and in the modern elaboration, often written 3-2-1-1-0: one copy offline or immutable, and zero untested restores. Each clause answers a specific way things die. The second copy exists because a single drive holding the only spare is one power surge from a funeral; storage is rated by annual failure rates, and a ten-thousand-hour mean-time-to-failure is a probability, not a promise. Two media types exist because correlated failure is real: a batch of identical drives from the same production run can die together, and every technology has its own poison — magnetic disks die mechanically, SSDs lose charge and leak data when stored unpowered for months, flash cards corrupt, optical disc dyes fade, and tape is fine until humidity gets to it. The offsite copy exists because fires, floods, theft and lightning strike locations, not files: a backup drive sitting next to the computer it backs up shares the insurance policy of the desk it rests on. The mathematics of independent failure is the whole argument — copies fail independently only when their media and their locations differ, which is precisely what the rule mandates and what a folder of identical USB sticks does not provide.
The Failure Modes 3-2-1 Does Not Cover
Honest version first: the rule protects against hardware death and disaster, and is almost useless alone against the two modern killers. Ransomware encrypts the live data and, if it can reach them, the attached backups — the fix is the extra clauses: one copy that is truly offline (a powered-down drive, tape in a cupboard) or immutable (object storage with write-once retention, where the storage provider enforces that a written object cannot be overwritten even by the account owner). Silent corruption — bit rot, a partial write, a bug in the backup tool itself — means the backup that "succeeded" for three years contains garbage; the fix is verification: checksums compared periodically, and actual test restores, not a glance at a green progress bar. Then the category of human disaster nobody budgets for: accidentally deleting the source and the synced backup in the same afternoon, which is why sync is not backup — the single most expensive misunderstanding in consumer data management. Dropbox, Drive and their cousins replicate your mistakes instantly and, once history rolls past thirty days, irreversibly; a backup is a one-way, time-delayed copy that refuses to follow you into your own errors. And account-level loss — the provider outage, the locked cloud account, the region deleted along with the login that could reach it — argues for the offsite copy being one you physically control, or at least a second provider.
The Practical Shape of a Real System
Written as a home or small-office plan, the rule stops being a slogan. Copy one: the working data on the machine. Copy two: an automatic local backup — in the Windows world File History or a versioned image tool, on macOS Time Machine onto a dedicated disk, on Linux something like restic or borg — attached, hourly or daily, and never the same physical device as the data. Copy three: an offsite copy, which for most people is now object storage (Backblaze B2, Wasabi, Cloudflare R2, the provider's own archival tier) reached by an encrypted, versioned, append-only tool rather than a mirrored folder, with retention long enough that last month's mistake is still recoverable. Add the offline or immutable twist for the ransomware clause: a monthly backup to a disk that then goes into a drawer, or a storage bucket with object-lock enabled. Then the two disciplines that separate a system from a wish: automation — backups that depend on remembering are backups that do not exist, which is the entire lesson of the silent R2 backup failure story — and restore drills: once a quarter, actually recovering a real folder, or a whole machine image, from the offsite copy, timing it, and finding out in a calm week rather than a worst week whether the archive opens. A backup strategy without a restore schedule is just storage with extra steps.
The Questions That Decide How Much to Spend
Two numbers set the budget, borrowed from business continuity and equally true for a family photo library: RPO, recovery point objective — how much recent data you are willing to lose, which dictates backup frequency — and RTO, recovery time objective — how long you can function without the system, which dictates whether restore means downloading forty gigabytes from cold storage over a weekend or booting a spare machine in ten minutes. Almost everything at consumer scale is RPO-driven: a day of lost photos is irreplaceable, a day of lost reinstallable applications is nothing, and the smart split is to back up ruthlessly what cannot be re-made — documents, images, video, the one-of-one database — and treat re-downloadable software as a manifest, a list of package names, not a copy. The deep point for anyone who has ever said "I will do it this weekend": data loss is not an event that happens to careful people and careless people differently; it happens to everyone whose copies are correlated in time, media, or location, and the 3-2-1 rule is simply the checklist that decorrelates them. Three copies, two kinds, one away, restore something on purpose before you need to.