Scenario · Multi-Database
Restore to the wrong database
A sandboxed PostgreSQL incident — investigate with your own tools, submit a fix, and get deterministic Detect / Fix / Trap scoring.
L3 · 10–15 min · runs locally in Docker
Launch
Start this scenario
Boot it in a real PostgreSQL sandbox and investigate with psql, EXPLAIN and pg_stat_statements.
ride postgres start stage-06/04-restore-wrong-databasePart of these paths
Show the postmortem & investigation hints spoilers
Restore to the wrong database
Type: incident simulation · Topic: Multi-Database · Level: L3 · Duration: 10–15 min
Launch: ride postgres start stage-06/04-restore-wrong-database
POSTMORTEM (root cause · how it was found · the fix · lesson)
Root cause: a restore into restore_target completed successfully, but it restored
the wrong source — the analytics snapshot ('analytics-copy') instead of production
app_db ('app-production'). The restore was technically green; operationally it put
the wrong database's data in the target.
How it was found: verifying the restore TARGET (current_database + the db_identity
marker) showed the analytics snapshot, not the expected production one. Checking
app_db itself would have proved nothing about the target.
The mitigation: restore the correct source into the target
(`pgpg action restore-correct` restores app_db into restore_target); the marker
then matched 'app-production'.
Lesson: a successful restore is not a correct restore. Verify the target's
identity and data against what you expected — in a multi-database cluster it's
easy to restore the wrong source. Re-restoring analytics or adding an index does
nothing.
INVESTIGATION HINTS (the staged path to diagnose and fix)
1. A restore into restore_target 'succeeded' — but did it restore the RIGHT database? Verify on the target: \connect restore_target then SELECT current_database(); SELECT * FROM db_identity; the marker says 'analytics-copy', not the expected 'app-production'.
2. The wrong source was restored: restore_target holds the analytics snapshot. Production is app_db (identity 'app-production'). Don't validate app_db itself and call it done — check the restore TARGET.
3. Restore the correct source into the target: `pgpg action <session> restore-correct` (restores app_db into restore_target). Then restore_target shows 'app-production'. Don't restore analytics again and don't add indexes.