Verify my database backup setup end to end. An untested backup is a wish, and I don't want to find out on the worst day of the launch that mine is broken. Check each of these: 1. Backups exist and run automatically. Confirm the schedule (daily minimum for a live app, ideally point-in-time recovery for anything transactional) and confirm recent backup files or snapshots are present with sensible retention (a week of dailies at minimum; longer for compliance if I need it). 2. Backups live somewhere separate from the production database. A backup in the same account/region that gets deleted when the account is compromised or the region goes down is not a backup. 3. Restore actually works. Restore the most recent backup into a temporary database, run a few sanity queries against it (row counts on key tables, a spot check of a recent record), and confirm the restored data matches what's live. This is the step everyone skips and it's the whole point. 4. Document the restore procedure: exact steps to restore into production or a new instance, who has the credentials to do it, and roughly how long a full restore takes (so I know whether the RTO is minutes or hours). 5. If I'm using a hosted database (RDS, Neon, Supabase, etc.), confirm point-in-time recovery is enabled and confirm I know how to invoke it, not just that it's turned on. Don't accept 'the platform handles it' as verification. The deliverable is a documented restore run against a real backup, the runbook checked into the repo, and any gaps flagged with a fix (missing schedule, missing off-site copy, or unclear procedure).