Perform a full restore drill

An untested backup is a hope, not a plan. A full drill tests more than bytes. It tests account access, keys, software availability, time, storage capacity, and written procedures — every link in the chain you’ll depend on when it’s real.

The rule that makes a drill honest: use only what would survive the disaster. Documented instructions, stored credentials, downloadable tools. If you fill a gap from memory during the drill, the drill has found a bug in your runbook. Write it down.

Run the restore

Restore the latest known-good lab snapshot to a fresh location:

mkdir full-restore
time restic restore SNAPSHOT_ID --target full-restore

restoring snapshot 4a72fb18 of [/home/flavio/notes] at 2026-08-03 09:12:33 to full-restore
Summary: Restored 48 files/dirs (3.845 MiB) in 0:02

real    0m2.311s

Wrapping the command in time matters: measured elapsed time on a realistic dataset is the only honest input to your RTO. A 2-second lab restore scales very differently when the real dataset is 200 GB behind a slow uplink.

Verify like you mean it

Measure elapsed time and verify file counts, checksums, permissions, and application startup where relevant:

find full-restore -type f | wc -l        # expect the snapshot's file count
diff -r notes/ full-restore/notes/       # silence means identical
stat full-restore/notes/report.txt       # spot-check ownership and mode

For an application dataset, the real verification is starting the application against the restored files and clicking around. Files that exist but don’t produce a working service are a failed restore that looks successful.

Record every missing dependency as you hit it: the password you had to look up, the restic version you had to guess, the disk that was nearly too small. Each one is a runbook fix, and finding them now is the entire value of the exercise.

Keep the drill safe

A drill must not endanger live data. Use a disposable destination and isolated service configuration. Never point a drill’s restored application at production databases or credentials — a “test” service that sends real emails to real customers is its own incident. The drill should be boring for everyone except your documentation.