Untested backups aren't backups. They're hopes. Here's how to prove yours actually work — the full restore drill I run.
What you need
- A scratch server or local environment (doesn't need to be powerful)
- Your latest backup files (database dump + files archive)
- About an hour
Step 1: Set up the scratch environment
Spin up a fresh Ubuntu box or Docker container. Install the same PHP version your production site runs — version mismatches cause the weirdest restore failures.
Step 2: Restore the database
mysql -u root -p new_database < backup.sql
Then verify: count the tables, check that wp_options has your site URL. If the dump is corrupted or incomplete, you want to know now.
Step 3: Restore the files
Extract your files archive to the web root. Check that wp-config.php is there (some backup tools exclude it — that's a nasty surprise at 2am).
Step 4: Point and test
Update wp-config.php with the new database credentials. Add this to your local /etc/hosts:
127.0.0.1 yoursite.com
Now browse the site. Click around. Log into wp-admin. Upload a test image. If everything works, your backup is real.
Step 5: Document what you learned
Write down every step you took, every gotcha you hit. That's your disaster runbook. Next time you're restoring at midnight with the site down, you'll thank past-you.
How often?
Quarterly at minimum. After every major change (host migration, PHP upgrade, big plugin update).
The full backup process — 40 checkpoints across 7 zones covering inventory, automation, encrypted offsite copies, and monitoring — is in my WordPress Backup & Disaster Recovery Checklist. The restore drill above is Zone 5.
Top comments (0)