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:
- Provision an isolated environment — never the production server. A disposable VM or a container:
docker run -d -e POSTGRES_PASSWORD=test postgres:16-alpine. - 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. - Unpack and check archive integrity:
gunzip -t latest.sql.gzcatches corruption before you go any further. - Restore:
gunzip -c latest.sql.gz | psql -h localhost -U postgres -d testdb, watching for errors (missing objects, non-existent roles, absent extensions). - 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.
- row counts on critical tables against expected thresholds (
- Measure total time and compare it against the RTO defined for that asset.
- Document: date, backup tested (identifier + hash), results, duration, anomalies. Without a trace, the test has no audit value.
- 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 criticality | Recommended test frequency |
|---|---|
| Production databases | Weekly to daily (automated) |
| Important business data | Monthly |
| Archives and cold data | Quarterly to twice yearly |
| Minimum for ISO 27001 / NIS2 audit | Evidence 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.