Backups that work: the 3-2-1 rule

The backup that exists and the backup that saves you

Making a copy is easy. Getting that copy to hand your data back, intact, on the day the disk catches fire is another thing entirely — and it's the only thing that counts. Between the two sits a space full of small details you notice only once it's too late: the dump that got cut off halfway and nobody checked, the copy that lived on the same machine that died, the encrypted file whose password walked out with the old laptop.

The 3-2-1 rule is an old, well-worn shorthand for avoiding almost all of those endings. It isn't a law or a product; it's a way of counting your copies so you can spot the weak point before an incident spots it for you.

What the rule says, and what it really means

Three copies of the data, on two different kinds of media, with one kept off-site. Counted honestly, the live data in production is already the first copy — so in practice you're talking about your working data plus two more.

A typical setup, and plenty for most: the data on the server, an automatic copy on a separate disk (a different medium, ideally physically separate rather than just another volume on the same system), and a third that leaves the building — to another machine somewhere else, or to remote storage. The "two media" part stops a single fault, like a dying disk controller or a corrupt filesystem, from taking original and copy together. The "one off-site" part stops a site-wide problem — a fire, a theft, a cascading delete, a provider having a bad day — from swallowing everything under one roof.

Why a copy on the same machine doesn't count

This is the most common trap: someone schedules a copy and drops it in another folder on the same server. It feels like coverage, and it does cover one case — an accidental file deletion — but only that one.

Think about what actually takes a server down. A disk that dies takes its partitions with it, the data one and the backup one alike. Malware that gets in through a leaked credential encrypts everything the account can write to, and the backup folder is usually on that list. A delete command fired as root in the wrong directory doesn't tell data and copy apart. In all three, the local copy goes down at the same moment as the original.

The off-site copy is what breaks that chain — precisely because it sits somewhere else and, done properly, out of reach of the same account that runs the server.

Rotation: keeping history without filling the disk

A single copy that gets overwritten every night has a gaping hole: if the trouble crept in three days ago and you don't notice until today, your only copy is already a copy of the trouble. So you keep a history — several generations — and prune the old ones so the disk doesn't overflow. That's rotation.

A sensible cadence keeps plenty of recent copies and fewer as they age: a handful of dailies, a handful of weeklies, maybe the odd monthly. Enough to roll back to a point before the disaster even if it took you days to catch it, without hoarding years of dumps nobody will ever open.

The pseudocode below captures the whole gesture: copy, push it off-site, prune the history, and — the line that usually gets dropped — every so often, check that a copy actually restores.

# every night: copy + prune the historycopy data to local-copycopy local-copy to off-site   # the one that actually saves youkeep 14 daily, 8 weekly; delete the rest# once a month: prove it restores for realrestore todays-copy to a scratch locationif the data checks out → ok; if not → alert

Two things are worth spotting here. The copy that "actually saves you" isn't the local one; it's the one that leaves. And the pruning has an order — keep what's defined, delete the rest — so a disk-space hiccup can't end up wiping what it shouldn't.

Test the restore: the step almost nobody takes

A backup that's never been restored isn't a backup; it's a hypothesis. The dump might be corrupt, it might be missing a table, the job might have been failing quietly for weeks because nobody read the alert. None of that shows up when you look at the file size. It shows up the moment you try to bring it back.

The test isn't about overwriting production with the copy — that would be pushing your luck. It's about restoring into a separate, throwaway environment and checking the data adds up: that the record count makes sense, that a few known values sit where they should, that the application starts against it. A checksum or a quick count answers the only question that matters — is this any good?

Make it a routine, not a "when there's time" thing. Once a month is a reasonable starting point for most; the more critical the data, the more often. And time it while you're at it — the real day is a poor moment to learn that recovery takes six hours when the business could stomach two.

How much you can lose, and how long you can wait

Two questions settle most of the rest. First: if something fails right now, how many hours of data can you afford to lose? If the answer is "not a whole morning," then a nightly copy isn't enough and you copy more often. Second: when it's time to restore, how long can you be down? That tells you how fast recovery has to be and where the copy should sit to be reachable in time.

Putting a number on those two — even a rough one — orders the rest of the design: how often to copy, how many generations to keep, and whether the off-site copy can take hours to arrive or has to be ready in minutes.

Encryption, and one copy nobody can touch

If the copies hold personal or customer data, they travel and rest encrypted. It isn't only about compliance: an unencrypted copy sitting on remote storage is a breach waiting to happen. The cost of encrypting is that the key becomes as valuable as the data — lose it and you've lost the copy as surely as losing the disk — so the key lives apart, somewhere that's itself backed up, and never beside the only copy it protects.

There's one more rung for those who can manage it: make at least one copy immutable or offline, so that not even a stolen credential with every permission can delete or encrypt it. That's the direct answer to ransom-by-encryption — if the good copy can't be touched from the compromised server, the blackmail has no lever.

Signs your copies aren't worth as much as you think

You don't need a deep audit to spot a fragile setup. A few symptoms give it away:

• Nobody can say when the last restore was, or the answer is "never."
• The only copy is on the same server — or the same provider, under the same account.
• Failure alerts go to an inbox nobody reads, or there are no alerts at all.
• There's no history: today's copy overwrites yesterday's.
• Everyone knows "there are backups," but nobody knows what's in them or what's left out.

Any one of these turns a backup into a false sense of security — which is worse than none at all, because it lowers your guard.