Recovery validation guide

Database restore drill checklist.

A backup job marked successful proves that a command completed. A restore drill tests whether the artifact, credentials, tooling, documentation, and recovery process work together.

Use this checklist for PostgreSQL, MySQL, MongoDB, or another database engine. Run every drill against an isolated target that cannot overwrite production.

1. Define the recovery objective

  • Record the database, environment, owner, and business service.
  • Define the recovery point objective (RPO).
  • Define the recovery time objective (RTO).
  • Choose the exact backup artifact to test.
  • Record who authorized the drill.

2. Protect production

  • Use an isolated host, instance, container, or database name.
  • Confirm the restore target is not referenced by production applications.
  • Disable outbound integrations, scheduled jobs, and notification workers on the target.
  • Require explicit confirmation before overwrite or destructive restore options.
  • Verify enough temporary and destination disk space is available.

3. Verify the backup artifact

  • Confirm the artifact exists at the expected local or object-storage path.
  • Record its creation time, size, format, compression, and checksum where available.
  • Verify encryption keys and credentials are available through the approved process.
  • Confirm the matching database client and restore tools are installed.
  • Check that the artifact belongs to the expected database and backup type.

4. Execute the restore

  • Record the start time and operator.
  • Capture the exact target and restore options.
  • Preserve native database-tool output and error logs.
  • Do not treat process exit alone as proof of recovery.
  • Record the completion time and calculate elapsed recovery time.

5. Validate recovered data

  • Confirm the restored database starts and accepts connections.
  • Verify expected schemas, collections, or tables exist.
  • Compare representative row or document counts.
  • Run application-specific integrity queries.
  • Confirm expected users, permissions, extensions, and indexes.
  • Test a read-only application workflow where practical.
  • Record missing or inconsistent data and the likely recovery-point gap.

6. Preserve recovery evidence

  • Backup artifact identifier and location
  • Source and target database details
  • Restore start, finish, and elapsed time
  • Operator and approver
  • Restore command or workflow options
  • Native logs and validation results
  • RPO and RTO result
  • Final status: passed, passed with exceptions, or failed

7. Close the drill

  • Document every manual step that was not in the runbook.
  • Create corrective actions for failures, missing tools, permissions, or unclear ownership.
  • Update the recovery procedure while the details are fresh.
  • Remove or secure restored sensitive data.
  • Schedule the next drill and rotate through backup types and storage locations.

Suggested cadence

  • Critical databases: monthly or quarterly
  • Important production databases: quarterly or semiannually
  • Lower-risk databases: at least annually
  • After major database, storage, encryption, or backup-tool changes: run an additional drill

Related resources

Next step

Turn the checklist into a repeatable recovery workflow.

Use DBAegis Community for evaluation, or email info@ilogicsoft.com to discuss a guided production walkthrough.