Backups that actually restore

Ask any organisation whether it has backups and the answer is yes. Ask when it last restored one, start to finish, and the room goes quiet. Google’s SRE book puts it in one line: “No one really wants to make backups; what people really want are restores.”

3-2-1

The best-known rule is photographer Peter Krogh’s 3-2-1, from The DAM Book. A 2012 US-CERT paper, Data Backup Options, credits him and states it like this:

• 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).”

Each number answers a different disaster. Three copies survive one failing. Two kinds of media survive a fault that hits every disk of one kind, and one offsite copy survives losing the building.

Ransomware goes looking for backups

The rule predates modern ransomware, which doesn’t just encrypt the files in front of it. The CISA and MS-ISAC #StopRansomware Guide warns that many ransomware variants try to find and delete or encrypt any backups they can reach. Its advice: “Maintain offline, encrypted backups of critical data”, because “it is important that backups are maintained offline.”

The guide also mentions immutable storage, which some cloud vendors offer and which can’t be changed or deleted for a set period, and adds a caution: “Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost.”

A USB drive that’s always plugged in is reachable. So is a cloud backup whose admin password sits on the infected network. Distance doesn’t make a copy safe; reachability is what decides it.

Sync is not backup

A folder that syncs to the cloud feels like a backup, but it copies everything faithfully, including a deletion, an accidental overwrite, or a file the ransomware just encrypted, within seconds. A backup has history: you can go back to how things were before the mistake. That matters most for mistakes nobody notices for a week or two.

Try all of it on a small office. Tick the copies it keeps, then throw disasters at them. Run a restore drill too: one of these copies isn’t what it seems.

mkdir -p drill/data && cd drill
printf 'invoice 1\n' > data/invoice-1.txt
printf 'invoice 2\n' > data/invoice-2.txt
find data -type f -exec sha256sum {} + > checksums.txt   # what "correct" looks like
tar -czf backup.tar.gz data                              # the backup
rm -rf data                                              # the disaster
mkdir restore && tar -xzf backup.tar.gz -C restore       # restore somewhere new
cd restore && sha256sum -c ../checksums.txt              # every line must say OK

cd .. && rm -rf restore && echo junk > backup.tar.gz
mkdir restore && tar -xzf backup.tar.gz -C restore       # tar refuses: not in gzip format
cd restore && sha256sum -c ../checksums.txt              # every line says FAILED open or read