Prove a monthly restore drill for auditors
A backup job that finished is not recovery. A scheduled restore drill restores into a clean directory to a point in time, asserts a known row before the target survives and a row after it does not, and records the date as the ‘last proven restore’ an auditor can actually read.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Most teams monitor the backup job and stop there. But a green backup proves only that files were written; it says nothing about whether they restore, whether every required WAL segment is present, or how long recovery takes. Mission-critical and SOC2 both need the opposite evidence: a recent, successful restore into a clean host with an application-level assertion.
Meridian Freight needs to show that settlements can be recovered to a chosen moment. The drill restores a base backup plus archived WAL to a timestamp between two committed marker rows, then asserts the before-target row exists and the after-target row does not, the same measured mechanism proven in the native PITR harness, and stamps the drill date for the auditor.
Simple terms
Once a month, actually restore. Pick a moment in time, restore a backup up to that moment into a fresh directory, and check the data: one row you committed just before the target must be there, and one you committed just after must not. Write down the date it passed. That date, not last night's backup log, is your recovery evidence.
Full runbook for this incident
- The full identify checklist, the exact signals that tell you it's this incident
- Every diagnostic query; lab output is attached only to the steps we actually captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
Card required. Cancel before day 7 and you are not charged.
Related runbooks
Continue the same incident path
Sibling procedures that cover the adjacent setup, recovery, or prevention step.
More in this category
Other Mission-critical platform 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
Need the full procedure?
Pro runbooks finish the incident path
Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.