Restore to a point in time before the damage
A base backup plus archived WAL recovers to a chosen moment. Targeting a timestamp two seconds before a DROP TABLE brought all 500 rows back, with the server logging that it stopped before the transaction that did the damage.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Restoring the last base backup answers the wrong question. The damage is usually a single statement, and everything committed between the backup and that statement is still wanted. Point-in-time recovery replays the archived WAL up to a chosen instant and stops, which is what makes a recoverable window possible at all.
Meridian dropped a table in production. The base backup predates 500 rows of orders that were written afterwards, and those rows are still needed.
In plain English
A backup is a photograph of the database at one instant, and the write-ahead log is the film of everything that happened next. Restoring only the photograph throws away the film. Point-in-time recovery replays the film on top of the photograph and lets you shout stop at a chosen moment — so you can land just before the mistake, keeping every change that came after the backup and before the damage.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Backup & recovery runbooks
Neighbouring incidents that share the same diagnostic surface.
Connected
How this connects to the rest of the library
A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.
Fixes these errors