Practical guide

How to test your backup restores: a practical guide (manual vs automated)

A complete method for testing the restorability of your PostgreSQL, MySQL and file backups: step-by-step manual procedure, validation criteria, recommended frequencies, and automation with audit evidence.

June 2026· 4 min read·fr

How to test your backup restores

Definition. A restore test (or restore drill) means rebuilding a usable system from a backup, in an isolated environment, then validating the integrity and completeness of the restored data. It is the only method that proves a backup is genuinely recoverable — a "successful" backup job only proves the copy was written.

Why it is essential

According to Backblaze's State of the Backup 2024 survey, only 61% of enterprise restore attempts deliver the expected result. Compliance frameworks require it explicitly too: ISO 27001 (control A.8.13) calls for backups tested regularly with supporting evidence; the NIS2 directive (Article 21) mandates backup management and demonstrated recovery capability; and cyber insurers increasingly ask the question in their questionnaires.

The manual procedure, step by step

Example for a PostgreSQL dump stored on S3:

  1. Provision an isolated environment — never the production server. A disposable VM or a container: docker run -d -e POSTGRES_PASSWORD=test postgres:16-alpine.
  2. Fetch the backup from its real source (not a convenient local copy): aws s3 cp s3://backups/db/latest.sql.gz . — the fetch is part of the test: credentials, network, permissions.
  3. Unpack and check archive integrity: gunzip -t latest.sql.gz catches corruption before you go any further.
  4. Restore: gunzip -c latest.sql.gz | psql -h localhost -U postgres -d testdb, watching for errors (missing objects, non-existent roles, absent extensions).
  5. Validate functionally — the heart of the test:
    • row counts on critical tables against expected thresholds (SELECT COUNT(*) FROM users;);
    • presence of recent data (is the backup really from yesterday, not from March?);
    • referential integrity, constraints, indexes;
    • for files: presence of known "canary files" and their expected content.
  6. Measure total time and compare it against the RTO defined for that asset.
  7. Document: date, backup tested (identifier + hash), results, duration, anomalies. Without a trace, the test has no audit value.
  8. Clean up: destroy the test environment and the restored data.

Realistic cost: 1 to 4 engineer-hours per system, every single iteration. That is why manual tests always end up not being done any more.

Recommended frequencies

Asset criticalityRecommended test frequency
Production databasesWeekly to daily (automated)
Important business dataMonthly
Archives and cold dataQuarterly to twice yearly
Minimum for ISO 27001 / NIS2 auditEvidence less than 6 to 12 months old per critical asset

Automating it, with audit evidence

Steps 1 to 8 above are exactly what RestoreProof runs as a scheduled task:

  • a runner on your infrastructure does fetch → unpack → restore into an ephemeral container → validation probes (archive integrity, canary files, PostgreSQL/MySQL queries with thresholds, HTTP) → full cleanup (containers and volumes);
  • every run produces a timestamped, Ed25519-signed report: identifier and SHA-256 hash of the artefact tested, per-probe result, durations, PASS/WARN/FAIL verdict;
  • data and secrets never leave your infrastructure — only the signed verdict reaches the dashboard;
  • scheduling is a plain cron expression: 0 2 * * * and every night, yesterday's backup gets put to the test.

You move from a costly annual exercise to a continuous history of evidence — the kind the auditor, the enterprise customer and the insurer all ask for.

FAQ

Is restoring a single file enough? No. Restoring one file validates access to the repository, not recovery capability. A meaningful test rebuilds the system to the level required by the RTO: database started and queryable, application working.

Should you test against production data? The test must run against the real production backup (otherwise it proves nothing), but execute in an isolated, ephemeral environment that is destroyed afterwards. That's also why the test should stay inside your infrastructure: it handles real data.

What evidence should be kept for an audit? At minimum: date and time, identifier and hash of the backup tested, environment, validation results, measured duration vs RTO, verdict. A cryptographic signature on the report strengthens the integrity of the audit trail.


Sources to link: Backblaze State of the Backup Survey 2024; ISO/IEC 27001:2022 A.8.13; Directive (EU) 2022/2555 Art. 21; ENISA/NCSC guidance on restore drills.

how to test backup restorepostgresql restore testtest mysql backupbackup test procedurerestore drill
Early access

Ready to prove your restores?

RestoreProof automates restore testing and produces cryptographically signed evidence — without your data ever leaving your infrastructure.