Backups I actually test

2026-08-09

For years my backup strategy was "there is a cron job somewhere". It took one failed disk and a corrupt archive to change that. These days the rule is that every backup has a restore drill, and the drill runs on a schedule just like the backup does.

The layout

• Daily snapshots of the important directories on the home server, kept for two weeks.
• A weekly encrypted archive copied to a second machine in another room.
• A monthly copy to an external drive that lives in a drawer at a relative's place.

The drill

Once a week a script picks the newest archive, extracts it into a scratch directory, verifies every file against the checksum list written at backup time, and then removes the scratch copy. It writes one line to a log: date, archive name, file count, result. If the line says anything other than ok, I look at it the same day.

sha256sum --quiet -c manifest.sha256 && echo ok || echo FAILED

Twice a year I do a full restore by hand onto a spare machine, timing how long it takes. The first time took most of an afternoon because half the steps lived only in my head. Now there is a one-page checklist, and it takes under an hour.

What it caught

So far: one archive truncated by a full disk, one permissions problem that would have made the restored files unreadable, and one directory I had simply forgotten to include. None of these would have shown up until the day I needed the backup.