Why untested backups fail
Most small businesses back up their websites. Fewer ever restore those backups on purpose. The gap shows up on the worst morning: the site is down, a plugin update broke the homepage, or the host is locked—and the “backup” turns out to be the wrong database, an empty uploads folder, or a dump nobody knows how to open.
A restore drill is the fix. Once a month, on a quiet day, restore a recent backup somewhere safe (usually staging), verify the site actually works, and write down what failed. You do not need an enterprise DR program. You need a same-day checklist owned by a named person.
Backups are promises until someone proves them. Common failure modes TwoQM sees with WordPress, static, and hosted sites:
The backup job ran, but skipped wp-content/uploads (or your media bucket)
The dump is from the wrong environment—or an old production DB into an empty theme folder
Secrets live only in host env vars; the zip has code but not .env / wp-config credentials
SSL on staging is expired, so “the site is up” but browsers and form posts fail
DNS and mail still point at broken production while a private staging URL looks fine
The only person who knew the host panel password left last quarter
None of these require a sophisticated attacker. They require an untested routine.
What “restore” means for your stack
Define the scope before you click Restore.
WordPress (shared or managed host) — Files + database + uploads. Confirm object storage or CDN assets if media is off-box. Note plugin licenses and must-use plugins missing from the zip.
Static site (Netlify, Cloudflare Pages, S3+CDN, etc.) — Build artifact and the repo/commit that produced it. A CDN cache of last week’s HTML is not a backup of your content source.
Hosted / SaaS builders — Vendor export or snapshot—plus DNS ownership at your registrar. If the vendor holds the only copy, your drill is “can we rebuild from export + DNS in under X hours?”
Write the stack type on the drill sheet. Steps differ; ownership does not.
Same-day monthly drill (60–90 minutes)
Pick a fixed day and protect it like payroll.
1) Choose the restore target (not production)
Prefer a staging hostname. Do not overwrite live production unless you have documented rollback and a maintenance window.
Before restore: staging DNS or hosts-file access works; staging uses a separate database; you know how to flip SSL on staging; you have a recent backup labeled with date, environment, and contents.
2) Restore the pieces in order
1. Create or wipe the staging container
2. Restore files (or deploy the static build)
3. Restore the database or content export
4. Restore uploads / media if outside the main archive
5. Point staging config at staging DB and URLs (careful WordPress search-replace)
6. Load env secrets from your password vault—not from memory
If media is on S3 or a CDN, confirm staging can reach those objects or that you restored a media snapshot. Missing images are the most common “green homepage, broken business” outcome.
3) Verify like a customer
Do not stop at “HTTP 200.”
Homepage and two inner pages load with correct branding and recent content
A known media file returns 200
Contact or quote form submits to the monitored inbox (or CRM)
Checkout or booking works if you sell online—use test mode when available
CMS/admin login works with a company-controlled account
No mixed-content / SSL warnings on staging
SMTP still sends if forms use mail
Optional: compare post count or a content checksum so you know you did not restore last year’s dump.
4) Check DNS and mail ownership
Who can log into the registrar and change A/AAAA/CNAME records?
Are SPF/DKIM/DMARC documented so you could re-point mail without guessing?
If production failed tonight, could you change DNS to a rebuilt host within your target time?
You are not flipping production DNS during a routine drill. You are proving you could.
5) Log failures, fix the backup job
Capture backup ID/date, what was missing, time to restore and verify, owner initials, and next drill date. Then fix the backup configuration—not only staging.
Who owns the drill
Name one owner (and a backup):
Owner / ops lead: calendar, pass/fail sign-off, staging budget
Web/hosting contact (or TwoQM): restore, search-replace, SSL, form tests
Email DNS owner: mail paths after any future cutover
If “the designer handles backups” and that contractor has no staging access, you have a hope—not an owner.
Failure modes to expect
Site loads, images 404 — Uploads or bucket not in backup
White screen / DB error — Wrong DB credentials or env missing
Old posts / missing pages — Wrong dump date or environment
Forms fail silently — SMTP secrets missing; SSL blocking posts
SSL warning on staging — Expired or mismatched staging cert
“Works on my hosts file” — DNS/CDN still caching old production
Each row becomes a backup-job fix, not a shrug.
Bottom line
A backup you have never restored is a file, not a recovery plan. Block one quiet window each month: restore to staging, verify pages, media, forms, and admin login, confirm you control DNS and mail records, and write down what broke.
TwoQM helps small-business operators set up staging and a documented restore drill for WordPress, static, and hosted sites—so backups are something you can trust on a bad morning. Run the drill while the site is still up.