Your WordPress Backup Says Complete—So Why Won’t It Restore?

2 days ago

6 min read

A backup job finishes with a green check mark. Days later, a plugin update breaks the site, you press Restore, and the recovery stops halfway—or it completes into a blank page, missing images, broken logins, or an empty store. The uncomfortable lesson is that a completed backup is only evidence that files were copied. It is not proof that the site can be reconstructed.

When I review WordPress recovery failures, I separate the job into three questions: Did the backup capture everything? Can the archive be read? Can those files and database tables run together in the destination environment? This workflow answers them in that order so you do not overwrite the last good evidence with repeated restore attempts.

First: freeze the incident before you make it worse

If the live site is still receiving orders, form submissions, memberships, comments, or bookings, do not immediately roll the entire site back. A full restore can replace current database records with an older snapshot. Put the site into an appropriate maintenance or read-only state, record the time of the failure, and export the current database before changing anything.

If the failure followed an update, use Webcurry’s safe WordPress update-recovery checklist to isolate the component first. A targeted plugin or theme rollback may be safer than replacing the whole site.

Write down the last known-good time and the time the problem began.
Preserve a copy of the current files and database, even if they are broken.
Pause deployments, automated updates, imports, and cache purges.
For a store or membership site, decide how you will preserve data created after the backup.

Why a “successful” backup can still be incomplete

A typical WordPress site needs both its database and its files. The database contains posts, pages, users, settings, menus, plugin data, orders, and many configuration values. The files include WordPress code, themes, plugins, uploads, and configuration files. The official WordPress backup handbook explicitly treats database and files as two parts of a complete site backup.

That distinction explains several common traps. A Tools → Export file is not a full backup. The WordPress WP-CLI documentation notes that a WXR export contains content records but does not include site configuration or the attachment files themselves. Likewise, a copy of wp-content without the matching database cannot recreate users, settings, orders, or page-builder structures.

Before attempting a restore, identify exactly what you possess:

A database export such as .sql, .sql.gz, or a provider-specific database snapshot.
The wp-content directory, including uploads, active themes, plugins, and any must-use plugins.
wp-config.php or a secure record of its database credentials, salts, table prefix, and environment-specific settings.
Web-server rules such as .htaccess or equivalent Nginx configuration where relevant.
A record of the WordPress, PHP, database, theme, and critical plugin versions used when the backup was created.

Step 1: inspect the backup before importing it

Do not start by uploading the archive over the live site. Copy it to a separate working location and inspect it. A believable filename and a large file size are not enough.

Open the archive and confirm it can be decompressed without errors.
Check that the database dump is not zero bytes and contains WordPress tables rather than an error page saved as a file.
Confirm the expected uploads folders and recent media files exist.
Look for the active theme, custom child theme, must-use plugins, and any custom code outside the standard folders.
Compare the backup timestamp with the event you are trying to reverse.

If the archive is encrypted, verify that the recovery key is available before the incident. A backup you cannot decrypt is not a recovery path. If the backup lives only on the same hosting account as the failed site, copy it elsewhere before making destructive changes.

Step 2: restore to staging, not over the only live copy

The most useful backup test is a real restore into an isolated staging environment. Use a separate database, a separate directory or subdomain, and block public indexing. The staging server should initially match the production PHP and database versions closely enough to expose backup problems without adding a second migration at the same time.

A controlled restore normally follows this order: create an empty database, import the backup, place the matching files, update database credentials, adjust the site URL if the staging address differs, then log in and test the customer journey. WordPress documents database import through tools such as phpMyAdmin and WP-CLI; the WP-CLI database commands include both export and import operations.

Keep the original backup untouched. Work from a copy so a failed extraction or partial import cannot damage your only recovery set.

Step 3: diagnose the first restore error, not the final blank page

A white screen after restore is only the last visible symptom. The first error in the server log usually identifies the layer that failed. Turn on logging in the staging environment, reproduce the failure once, and read the earliest relevant PHP, database, or web-server error.

Database connection errors: confirm the database name, user, password, host, and privileges in wp-config.php.
Missing-table errors: compare the table prefix in wp-config.php with the imported table names and confirm the dump was complete.
Syntax or fatal PHP errors: restore the PHP version used by the backup or update the incompatible theme or plugin in staging.
Permission errors: correct file ownership and permissions instead of making the entire site world-writable.
Timeout or memory errors during import: use the host’s database tool or WP-CLI and split very large jobs where the platform supports it.

Step 4: fix URL changes without corrupting serialized data

A restore to another domain, protocol, or directory often appears successful while links, images, widgets, and page-builder data still point to the old location. WordPress stores some values in serialized form, so a raw find-and-replace inside the SQL file can corrupt length markers.

Use a serialization-aware method. The official WP-CLI search-replace command handles serialized data and supports a dry run. Start by measuring the proposed change before writing it:

wp search-replace 'https://old.example' 'https://staging.example' --dry-run

After the dry run looks correct, perform the replacement on staging, clear only the relevant caches, and retest. If visitors still see an older version, follow the layer-by-layer website cache diagnostic rather than repeating the restore.

Step 5: treat WooCommerce and other live data separately

A brochure site can often return to one clean snapshot. A live store cannot assume that. Orders, stock changes, refunds, customer accounts, subscriptions, and payment tokens may have changed between the backup time and the incident.

WooCommerce’s own backup guidance highlights database and file coverage, and its subscription documentation warns that restores may require reconstructing orders and subscription data created during the gap. That means the recovery plan needs a reconciliation step: compare payment-provider records, store orders, emails, shipping records, and any exports created after the snapshot.

Never ask a customer to pay again merely because an order disappeared. If payment and order data have separated, use the evidence-first process in Webcurry’s missing-order confirmation guide before retrying or refunding anything.

Step 6: prove the restored site works

A homepage that loads is not an acceptance test. Test the tasks that create business value and the background processes that make them reliable.

Open several old and recent pages, posts, images, and downloadable files.
Log in as an administrator and as a normal user where applicable.
Submit a real test form and confirm both the database record and the delivered notification.
Complete a sandbox purchase, booking, or membership flow and verify the resulting record.
Check scheduled tasks, webhooks, search, redirects, canonical URLs, analytics, and consent behavior.
Review mobile layouts and critical pages in more than one browser.
Confirm backups can run again from the restored environment and that the next archive is stored off-host.

If a restored contact form reports success but no message arrives, diagnose the storage and delivery chain with Webcurry’s contact-form delivery guide. If performance changes after recovery, compare the restored stack against the WordPress performance workflow instead of installing another optimisation plugin immediately.

Build a backup system around restore evidence

The durable fix is not simply “back up more often.” It is to make recovery observable. Keep more than one retention point, store at least one copy away from the production host, protect encryption keys separately, and record what the backup includes. Schedule periodic staging restores and log the result: archive opened, database imported, uploads present, admin login worked, and the critical transaction completed.

Also define ownership. Someone should know who checks failed jobs, who can access the off-site copy, who approves a production restore, and how post-backup orders or leads will be reconciled. Those operational details belong in a practical website maintenance plan, not in a password-protected note that nobody tests.

A backup is only useful when recovery is repeatable

The green “backup complete” message is the start of verification, not the finish line. Confirm that the archive contains both database and files, restore a copy to staging, diagnose the first error, protect data created after the snapshot, and run a business-level acceptance test. Once that path works without improvisation, you have more than a backup—you have a recovery process.

If the archive exists but the restore path is unclear, ask Webcurry to review the backup and recovery workflow before replacing the live database or files. A short evidence-led review is cheaper than discovering the missing component during an outage.