Here is an uncomfortable truth every sysadmin eventually learns the hard way: a backup you have never restored is not a backup. It is a hope. And hope has a way of collapsing at 2 a.m. on a Saturday when your database is corrupt, the client is calling, and the file you have been dutifully copying to cloud storage for eight months turns out to be a truncated, unreadable mess.
The statistic that should keep you up at night comes from industry surveys of IT disaster recovery: roughly one in three businesses that attempt a restore from backup during a real incident discover the backup is incomplete, corrupt, or missing critical data. Some estimates run higher. The backup ran successfully every single night. The restore had simply never been tested. Nobody thought to check, because "the job finished with a green checkmark" felt like proof.
This article walks you through how to actually test backup restore procedures before disaster strikes, not after. We'll cover the difference between a backup that exists and a backup that works, a full worked restore drill with real timings, a comparison of restore-testing approaches, and a repeatable checklist you can run every quarter. By the end, you'll be able to prove your backups restore, rather than assume it.
Key Takeaways
- A backup is only valid once you have successfully restored from it. Untested backups fail during real incidents about a third of the time.
- Run a full restore drill to an isolated environment at least quarterly, and after any major infrastructure change.
- Measure two numbers every drill: Recovery Time Objective (RTO) — how long the restore takes, and Recovery Point Objective (RPO) — how much data you lose.
- Verify data integrity after restore, not just that files copied. Check row counts, file hashes, and that the application actually starts.
- Keep at least one backup copy offline or immutable so ransomware can't encrypt it alongside your live data.
- Document every step so someone other than you can perform the restore under pressure.
Why a Backup That Exists Is Not a Backup That Works
There is a gap between "the backup completed" and "the backup can be restored," and that gap is where most disaster recovery plans die. A backup job can report success while quietly failing in ways that only surface during a restore:
- Silent corruption. A single flipped bit in a compressed archive can render the entire file unextractable. The backup software never noticed.
- Incomplete captures. The database was mid-transaction, or a file was locked, so it got skipped. The job still "succeeded."
- Missing dependencies. You backed up the database but not the uploads directory, or the config file, or the encryption key you now need to decrypt everything.
- Expired or wrong credentials. The restore requires a key or password that changed six months ago and nobody wrote down.
- Version drift. The backup was made with software version 4.2, and your restore machine runs 5.1, which can't read the old format.
None of these show up in a nightly status email. All of them show up during a restore. The only way to close the gap is to perform the restore before you need it.
The three-two-one rule, briefly
Before testing, make sure you have something worth testing. The classic guideline holds: keep 3 copies of your data, on 2 different media types, with 1 copy offsite. In 2024 many teams add a fourth digit: one copy that is immutable or offline, so a ransomware attack that reaches your live servers can't reach your last-resort backup. If you run a WordPress or e-commerce stack, layering in protection like eDarpan WordPress Protection or SiteGuard Pro reduces how often you'll need those backups in the first place — but never treat prevention as a substitute for a tested restore.
A Worked Restore Drill: 40 GB WordPress Site, Start to Finish
Abstract advice is easy to nod along to and impossible to act on. So let's run a real drill. Say you manage a mid-sized WordPress site: a 2.3 GB MySQL database, 38 GB of media uploads, plus themes, plugins, and config — roughly 40 GB total. Your backups run nightly to an S3-compatible bucket. Here is how you prove the backup restores.
- Provision a clean target (10 min). Spin up a fresh server or local VM that mirrors production: same PHP version, same MySQL major version, same web server. Do not restore into production. You want an isolated sandbox so a botched test can't hurt live data.
- Pull the latest backup (18 min for 40 GB on a 300 Mbps link). Download the most recent full backup from your offsite location. Time this step. This download speed is part of your recovery time, and people always forget it.
- Verify integrity before extracting (4 min). Run a checksum on the archive and compare it against the hash recorded when the backup was made. If you use
sha256sum backup.tar.gzand the hashes don't match, stop — the file is corrupt and the rest of the drill is moot. - Restore the database (7 min). Create an empty database, then import the SQL dump. Watch for errors during import, not just at the end. A dump that fails halfway can leave you with 60% of your tables and no warning.
- Restore files (12 min). Extract the media and application files to the correct paths. Confirm ownership and permissions match production, or the site will throw 500 errors even though every file is present.
- Reconnect and boot (5 min). Update
wp-config.phpwith the sandbox database credentials and site URL. Load the homepage. - Validate, don't just glance (15 min). This is the step most people skip. Compare database row counts against production. Open five random uploaded images. Log into the admin. Run a checkout on a test order if it's an e-commerce site. Confirm the newest content — from yesterday — is actually present, which proves your RPO.
Total time: roughly 71 minutes. That number is your real RTO for this restore path, and it is almost always longer than management assumes. Now you have data instead of a guess. If step 7 revealed that yesterday's 40 orders were missing, you've just learned your RPO is worse than 24 hours — before it mattered.
What "validate" actually means
File count and byte size are the weakest possible checks. A restore can pass both and still be broken. Real validation means the application works: users can log in, the newest data is present, images render, and background jobs run. Tie this to your monitoring so you catch regressions. The Webmaster Tools Suite is handy here for confirming a restored site responds correctly and its pages resolve the way production did.
Restore-Testing Approaches Compared
Not every organization needs the same level of rigor. A hobby blog and a payment processor have very different tolerance for downtime and data loss. Here's how the common approaches stack up.
| Approach | Effort | Confidence | Best For | Recommended Frequency |
|---|---|---|---|---|
| Checksum verification only | Very low | Low — proves the file isn't corrupt, not that it restores | Small personal sites | Every backup (automated) |
| Partial restore (spot check) | Low | Medium — proves data is readable | Blogs, small business sites | Monthly |
| Full restore to sandbox | Medium | High — proves the whole stack recovers | E-commerce, SaaS, client work | Quarterly |
| Automated restore pipeline | High to build, low to run | Very high — restores continuously in CI | Regulated or high-availability systems | Weekly or per-backup |
| Full DR failover drill | Very high | Highest — proves people and process too | Enterprises, critical infrastructure | Annually or semi-annually |
My honest recommendation for most teams: automate checksum verification on every backup, run a partial spot-check monthly, and schedule a full sandbox restore quarterly. That combination catches nearly every failure mode without eating your week. Scale up to automated pipelines only when downtime genuinely costs you money by the minute.
Building a Repeatable Restore Test You'll Actually Run
The best restore test is the one that happens. Elaborate procedures that require a full day tend to get skipped, so design for repeatability from the start.
Script the boring parts
Every step that can be automated should be. Downloading the backup, verifying the hash, provisioning the target, importing the database — these are all scriptable. When the entire drill is a single command you can run on a Friday afternoon, you'll run it. When it's a 30-step manual runbook, you won't.
On Windows, restore tests often involve juggling paths and mirrored directory structures. A tool like Windows Symlink Creator Pro makes it far simpler to point a restored application at test data without copying gigabytes around or hard-coding paths. Small friction removers like this are the difference between a drill that runs quarterly and one that never runs.
Record the metrics every time
Keep a simple log of each drill:
- Date and backup age — how old was the copy you restored?
- RTO — total wall-clock time from "start" to "application verified working."
- RPO — how much data would you have lost, measured in minutes or hours?
- Failures found — anything that broke, and how you fixed it.
Over a few quarters this log becomes gold. You'll spot RTO creeping up as your data grows, notice when a config change quietly broke the restore path, and have real numbers to show stakeholders instead of reassurances.
Store your runbook where you can reach it during an outage
If your restore instructions live only on the server that just went down, you have a problem. Keep the runbook — credentials references, step order, gotchas — somewhere independent and shareable. A secure snippet and note tool like LionPaste works well for keeping restore commands and configuration notes accessible to the whole team, and for handing off the procedure so recovery doesn't depend on one person being awake and reachable.
Common Restore Failures and How to Prevent Them
After enough
Cover image: Example for viewing and restoring deleted content on Wikimedia Commons by Wikimedia interface authors (simple interface text probably doesn't pass the threshold of originality, i.e. no original authorship), licensed under BY-SA 4.0 via Openverse.
