Backup Restore Drill Evidence Checklist

Good For

• backup restore drills
• NAS and server backups
• VM image verification
• small-office recovery planning
• audit evidence

How to Use It

1. Open a ticket or worksheet for one protected system and record the system owner, business use, backup product, repository, retention policy, expected RPO, and expected RTO.
2. Identify the exact restore point being tested, including backup job name, backup timestamp, storage target, encryption or application credentials needed, and whether the backup is file-level, image-level, database-aware, or VM-aware.
3. Choose a safe restore target before touching production: a temporary folder, isolated test VM, non-routed recovery network, or vendor-provided sandbox restore location.
4. Restore a known file or application component first and record start time, finish time, file path, size, hash if practical, and whether permissions or ownership survived the restore.
5. For VM or image backups, mount or boot the restore in isolation and capture screenshots or notes for boot success, disk visibility, service state, and login success.
6. For application or database backups, verify the application opens against the restored data, not merely that the backup job reports success.
7. Compare the measured restore age and restore duration against the expected RPO/RTO and mark the drill pass, pass-with-exceptions, or fail.
8. Convert every exception into a follow-up task with owner, due date, and validation method, especially missing credentials, unknown encryption keys, failed test boots, stale restore points, or undocumented manual steps.

Execution Modes

• local
• remote-single-host

Inputs and Outputs

Inputs

• system name
• business owner
• backup product
• backup job name
• restore point timestamp
• expected RPO
• expected RTO
• safe restore target

Outputs

• operator-notes
• restore-evidence
• future-html-report

Validation

• A real file, VM, database, or application component was restored to a safe target and opened successfully.
• The measured restore point age is within the documented RPO, or the gap is recorded as an exception.
• The measured restore duration is within the documented RTO, or the gap is recorded as an exception.
• The evidence package is clear enough that another operator can repeat the restore without relying on memory.

Reporting

• ticket note with pass, pass-with-exceptions, or fail result
• restore drill worksheet with timestamps and evidence links
• exception list for missing credentials, stale backups, failed boot tests, or undocumented recovery steps
• future HTML restore-readiness report grouped by system owner and backup product

Safety Notes

• Restore to an isolated or clearly temporary target and never overwrite production data during a proof check.
• Confirm encryption keys, service credentials, and application secrets are available before declaring the backup usable.
• Do not treat a successful backup job status as proof of recovery; the proof is a usable restore.