Backups are promises. A restore test is when you actually pay the debt. I started doing quarterly restore drills after a real corruption event where my “good” backup was undeniably, quietly incomplete.
Two kinds of test
The quick one: restore a single file you know existed and check its contents. The real one: wipe a clone and rebuild from backup end to end. The quick test catches typos; the full test catches the things you did not think to back up.
restic restore latest -t /tmp/restore-test
# full rebuild onto a spare box:
restic restore <snapshot> -t /mnt/new-rootThe mistakes that bite first
- The backup runs, but silently skips a directory that moved.
- The remote copy is there, but the credentials expired six months ago.
- The restore works, but takes six hours and no one planned for the downtime.
Schedule it like anything else
crontab -e
# 0 4 1 * * /usr/local/bin/restore-drill.sh >> /var/log/restore.log 2>&1Put the drill on the calendar with the other routine work and log the result. The goal is not perfection; it is that when something breaks you already know the procedure and the number that matters — your restore time.
Data loss is not an if. It is a when, and the only thing between you and it is a test you have not done yet.