The audit asks for backup policy: 24h RPO, 30-day retention, "automatic snapshots included". Then: show the last successful restore. Last attempt: two years ago, partial, nobody remembers the test database password.
A backup policy without restore proof is a trust document — not an operational control. On shared hosting and cloud alike, silent failures are common: empty backups, corrupt dumps, revoked KMS keys, restore theoretically possible but never measured.
Why backups fail without you seeing it
Disk full — script runs, file truncated. Permissions changed — cron OK, write refused since update. Encryption — backup present, key lost or rotation undocumented.
Incomplete scope — files yes, database no; prod yes, side buckets no. Restore outside support SLA — host restores disk, not your app logic.
| Test | What it validates | Suggested frequency |
|---|---|---|
| Single file | Backup access, integrity | Monthly |
| Full database | SQL consistency, RPO | Quarterly |
| VM / volume | Infra RTO | Annual |
| Cross-region | Real DR | Annual if DR |
A backup never restored is a lottery — not insurance.
Run a credible exercise in four steps
Prepare an isolated environment, reference dataset, timer, and named owner. Restore from the same source as in crisis: host snapshot, restic, S3 dump.
Validate with checksum, business queries, and app login — not only "service starts". Document in a one-page report: gaps vs RTO/RPO, corrective tickets opened.
Invoke host support if the scenario includes their layer — note response time: that is also proof.
Contract with the host
Ask snapshot frequency, retention, whether restore is included or billed, support delay, and anti-ransomware immutability. Compare via directory and Backups: what included covers if available.
Align host backup and client backup (export outside account) — a single copy at the same provider is not always enough. Cross-check Backup location for copy mapping.
The peak: ransomware day
Decide and move forward without blind spots
Plan a restore test within thirty days with at least one full database scenario. Publish a dated internal report and assign corrective actions. Link the exercise with Continuity plan and compliance and Backup location. Use the compare tool if changing backup offer.
Frequently asked questions
How often to test a restore?
Annual minimum for critical data; quarterly if sensitive or frequent changes.
Is restoring one file enough proof?
No — vary file, database, VM, and cross-region DR scenarios.
Does the host test our backups for us?
Rarely readability of encrypted backups — test stays with you.
What to put in the proof report?
Date, source, duration, observed RPO, anomalies, next due date, and owner.
A credible backup policy starts with one sentence: last successful restore on … in … minutes.