Tutorial · migration-hosting · Published 2026-08-16 · 4 min read
Test your backup with a restore drill
Run a scheduled restore drill: test a backup restores files, database and config on a scratch server before the real recovery.
A backup is not proven until a restore works
A backup is a copy; a restore is the proof. The biggest lie in website ops is "we are backed up" typed next to a restore that has never run. Restores fail for decided reasons: a database dump that was corrupted by the exporter, files missing from a partial rsync, a config value (.env, wp-config.php) that names the wrong host, or a backup job that silently stopped a month ago. A scheduled restore drill catches each of these while the failure is cheap to fix.
A drill is different from the real restore: it happens on a scratch copy, works with a test domain or hosts-file, and never touches the live site. That is what makes it safe to run on a schedule.
Choose the restore target
Drill on something close to the real production shape:
- A scratch server or local environment running the same platform versions (the same PHP or node version, the same database) as production.
- A scratch database, not the live one: a mistaken drill must never overwrite active data.
- A test domain or a hosts-file entry so nothing external links, emails, or analytics point at the restored copy.
The drill, step by step
- Start from the backup. Fetch the latest files and database dumps from the same storage the recovery would use (the offsite copy, the object store, the retention bucket).
- Restore files first. Upload or extract the file archive to the scratch document root; confirm key files and folders exist and have the right permissions.
- Restore the database next. Import the dump into the scratch database and run any post-import steps your platform needs (search-replace for a changed domain is common).
- Point the config at the scratch target. Update
.envorwp-config.phpso the site reads the scratch database and the test host. - Load the site through the test host and walk the critical paths: a public page, an internal page, the login or admin, an image asset, and one deep URL. Correct output on those proves the copy works.
- Log the result with the date, the dump timestamp used, and what had to be fixed.
For time-boxed sites, a "files on the test host" drill can be coarser: restore the files and the database, then stop after the login works. The goal is to prove the mechanisms, not to polish staging.
What a drill typically finds
| Failure | Typical cause | Caught at step |
|---|---|---|
| Files restore but site 500 | Missing .env/config reference | Step 5 |
| DB restores but blank | Search-replace not run for the test domain | Step 5 |
| Login loops / admin fails | Restored DB still hooks to the live URL | Step 5 |
| Email points at the old host | MX or outbound records not part of the drill set | Step 3 |
Scheduling the drill
- Weekly debugging for the parts of the site that are heavily developed or recently changed.
- Monthly for a static middle.
- Quarterly for a full recovery including an email and DNS seam, matching the recoverability section of your hosting SLA.
Automate the "does the duct exist" part with a script that checks the backup job ran, the dump is non-empty, and the file count is plausible (the uptime monitoring setup covers the alarm loop). The drill itself stays a human activity: scripts cannot smell a config that points at the wrong database.
When recovery is the job
If a planned drill returns a site that cannot start when needed, treat it as the alarm it is, and fix the mechanism, not the symptom. A restore that works on the third try after fiddling is not an acceptable recovery; the config and the restore steps are not repeatable until they work from the unzipped archive in one clean pass. If you cannot get that on a scratch copy, get help before the production incident.
The restore order for WordPress and the pre-change backup rule fill in the recovery-facing siblings.