Run this checklist quarterly, against the service, not against the backup job. It answers one question: if the data were gone this afternoon, could this team get it back inside the RTO?
Pair it with linux-runbook-restore-procedure. This
checklist gates; the runbook executes.
How to use this checklist
Run it as a drill, not as a review meeting. Work down the items, run the command each one carries, and paste the output into the drill log. The items that carry no command assert a fact about the procedure or about the people - answer those from the last drill’s written record, not from memory. If nobody can point at the record, the answer is no.
Every critical item is a gate. One failing critical item
means this service cannot be restored inside its RTO today,
whatever the backup job’s exit status says; ticket it before
the quarter closes. The warn items describe the difference
between a restore that works and one that works under the
conditions of a real disaster - review them, but they do not
hold the gate.
Evidence lives in /var/log/restore-drill.log on the host
that performed the drill, alongside the signed sheet below.
linux-checklist-disaster-recovery reads both: its
runbook-tested and rto-met items are satisfied by this
drill’s log and by nothing else.
Sign-off
- Operator: _________________ Date: ___________
- Reviewer: ________________ Date: ___________
- Measured restore time: __________ RTO: __________