Backups
Backup recovery drills: prove the restore process before an outage
Backup recovery drills convert a theoretical archive into evidence. A drill should start from a declared failure scenario and end with a working recovered service or data set, measured recovery time, known data-loss window, and a list of missing credentials, dependencies, or steps.
Pick one failure scenario at a time
Examples include a deleted website file, lost database, destroyed VPS, corrupted WordPress site, unavailable production disk, or compromised account. Define what is assumed lost so the test does not quietly rely on production state that the real incident would remove.
Use an isolated destination to avoid overwriting live data.
Restore using the documented operator path
Have the person/runbook obtain backup credentials, select the recovery point, fetch/decrypt data, rebuild required runtime/configuration, restore databases/files, and bring the service up. Record every undocumented secret or decision.
Do not let the person who designed the backup silently supply missing knowledge during the drill without recording it.
Verify application integrity
Check known records near the backup timestamp, file counts or checksums where useful, application login, writes, scheduled jobs, DNS/TLS prerequisites, and integrations. A successful extraction command is not enough.
For databases, run application-level queries or consistency checks appropriate to the engine.
Measure RPO/RTO and feed gaps back
Compare recovered data time with the declared RPO and elapsed drill time with the RTO. Update retention, automation, documentation, monitoring, or staffing before the next drill.
- Define what is lost.
- Restore without hidden production dependencies.
- Validate the application.
- Record measured RPO/RTO.