How restore verification differs from having a backup

The most expensive sentence in website recovery is: “We thought we had backups.”

The backup plugin showed green. The host panel listed nightly snapshots. A .zip sat in a folder labeled old-site-backup-final-v3. Then the site was hacked, the host account was suspended, or an update collapsed the database — and none of those files could be turned back into a working site on a deadline.

Having a backup and knowing you can restore are different jobs. Maintenance programs that skip restore verification are storing hope, not running disaster recovery.

What “having a backup” usually means

In practice, “we have backups” often means one or more of:

• A WordPress backup plugin runs on a schedule and uploads somewhere.
• The host takes automatic account-level snapshots.
• Someone downloaded a full-site export once after launch.
• A developer keeps a copy on a laptop from last year.

Each of those can be legitimate — and each can fail silently:

• Plugin backups stop uploading when API keys expire or disk fills.
• Snapshots live on the same infrastructure that just burned down.
• Exports are incomplete (files without database, or database without uploads).
• Laptop copies are stale and nobody remembers the password.

Green checkmarks in a dashboard measure backup attempts, not recoverability.

What restore verification proves

Restore verification is the deliberate act of rebuilding the site from a backup on a separate target and confirming it works. A proper verification run answers:

• Does the archive extract completely without corruption?
• Does the database import without errors?
• Can you log into wp-admin with expected users?
• Do critical pages load with correct content and images?
• Do forms, search, and permalinks behave?
• For stores: does checkout reach payment in test mode?

You are not “testing backups.” You are practicing recovery before the fire drill is real.

Document the date, which backup generation you used, who performed the restore, and any gaps found (missing tables, wrong PHP version, broken cron). That log is what turns storage into a plan.

Why unverified backups fail in real outages

Incomplete scope

Backup jobs often grab wp-content and the database but miss must-use plugins, custom code outside the web root, DNS records, or environment config (cron, Redis, SMTP). Restore “succeeds” into a broken half-site.

Verification catches scope gaps when you still have time to fix the job definition.

Wrong timing

The last good backup might be before the malware infection — but the most recent snapshot is after, carrying the compromise. Without periodic restores, you discover this during panic, not planning.

Version mismatch

Restoring a PHP 7.4-era site onto a host running PHP 8.3 without adjustment produces white screens. A restore test on current hosting reveals compatibility before you delete production trying to recover.

Credential and access rot

Backups encrypted with a password in a former employee’s password manager. S3 bucket under an AWS account nobody can access. Host snapshot restore requires a support ticket — 48-hour SLA while the business is offline.

Verification includes confirming who can execute restore and how long it takes.

Update-induced corruption

Sometimes the backup ran — but while the database was mid-write during a bad update. The file exists; the data is inconsistent. Only an import test reveals that.

This is why plugin updates alone are not a care plan: updates without pre-update backups and tested rollbacks leave you one bad click from learning your archive is useless.

How often to verify restores

Rules of thumb:

• Quarterly minimum for business-critical sites.
• After major changes: migration, redesign launch, new ecommerce plugin, host move.
• Before bulk updates on production when no staging exists — restore proof is your rollback.
• Immediately if backup monitoring shows failures or storage alerts.

Brochure sites with low change frequency can stretch toward twice yearly — but not “never.”

Where verification should happen

Never overwrite production to “test.” Use:

• Staging subdomain on the same host.
• Local dev (Local WP, Docker, etc.) for file/database imports.
• Separate cloud instance for disaster-recovery drills.

Match PHP version and extensions as closely as practical. A restore that works only on your laptop is not a production recovery plan.

Who should own verification

Split roles clearly:

• Backup generation — plugin, host, or script; automated where possible.
• Monitoring — alerts when jobs fail or size drops unexpectedly.
• Verification — human confirms restore and critical paths.
• Runbook — written steps so a different person can execute at 3 a.m.

If your maintenance checklist assigns “backups” but not “restore tests,” assign an owner for verification today.

What good documentation looks like

Keep a one-page recovery sheet:

• Backup locations (URLs, buckets, host panel paths).
• Retention policy (how many days/generations).
• Last successful backup timestamp.
• Last successful restore test timestamp and environment used.
• Contacts for host support and DNS.
• RTO/RPO in plain language: “We can be back in four hours using last night’s backup; we accept up to 24 hours of content loss.”

Owners who have never seen this sheet are betting on faith.

Backup types — quick comparison

Approach	Good for	Verify by
Plugin to remote storage	WordPress file + DB portability	Full restore on staging
Host snapshots	Fast rollback on same account	Restore to temp URL; confirm not infected
Manual exports	One-off migrations	Import within 30 days of relying on them
Real-time replication	Large stores, low RPO	Failover drill, not just ping

No single type removes the need to practice restore.

The bottom line

A backup file is inventory. Restore verification is proof.

Maintenance that includes checked backups means someone regularly answers: “If production disappeared right now, could we rebuild from last week’s copy before the client’s deadline?” If the honest answer is “probably,” you do not have verified recovery — you have a file listing.

Close that gap on a calendar, not during an emergency intake. Everything else in prevention — supervised updates, monitoring, ecommerce checks — assumes you can roll back when those layers fail. Verification is what makes that assumption true.