Run these in order. The first three stop the bleeding — do them before you google anything.
Pause your app, workers and cron jobs. Every write after the incident overwrites data you might still recover. systemctl stop app or scale to zero.
AI agent, migration script, console session — kill its connection before it "helpfully" retries. Revoke its credentials if you're not sure.
Counter-intuitive but critical: dump what's LEFT before any repair attempt. Failed repairs make things worse. pg_dump dbname > damaged.sql
Point-in-time recovery needs the minute it happened. Check your app logs for the last good request if you're unsure.
Managed host PITR (Supabase/Neon/RDS), your own backups, replicas, local snapshots, even yesterday's staging copy. Don't start with the first idea — start with the most complete one.
Never restore over production. Restore side-by-side, verify the data is good, then switch. createdb restore_check && psql restore_check < backup.sql
Compare row counts of your critical tables between damaged and restored. You want to know what the restore loses (data written after the backup) before you commit to it.
What happened, what saved you (or didn't), what changes today. If the answer to "what saved you" was luck — fix that while the pain is fresh.
OopsDB snapshots your database every 5 minutes, encrypted, locally — restore in one command. Free CLI, works with Postgres, Supabase, MySQL and SQLite.
npx oopsdb init →