This is a talk about backups. Not the impressive kind — the kind you actually run on a Tuesday at 03:00.
Why backups fail
Most backup failures aren’t technical. They’re organizational. Someone set up the job three years ago, it runs, no one checks it, and then the recovery drill reveals the retention window was set to seven days when you needed thirty.
The fix is boring: a runbook, a calendar reminder, and a person who is responsible for verifying that the restore works. Not a tool. Not automation. A person.
What to actually test
Running a backup is not the same as having a backup. Test the restore. Every quarter, at minimum. Time the restore — not because the number matters, but because knowing it exists in your muscle memory matters.
aws s3 cp s3://my-backup-bucket/2026-05-04/db.dump.gz ./restore/
gunzip ./restore/db.dump.gz
pg_restore -d mydb ./restore/db.dump
The callout
The boring work is the work that keeps your weekend yours.