How to restore a WordPress backup without making things worse

Before you restore a WordPress backup

The instinct during an incident is to restore immediately. Two minutes of preparation prevents the most common way restores go wrong, which is destroying evidence or data you turn out to need.

1. Back up the current broken state. It contains the cause of the problem and possibly recent data that is not in your restore point
2. Identify when the problem started, as precisely as you can, and pick a restore point from before it
3. Work out what falls in the gap: orders, form submissions, comments, posts, user registrations
4. Confirm the backup is complete, containing both files and database, and that it is not itself from a broken state

That third point is where real damage occurs. Restoring a shop to yesterday morning erases every order placed since. The orders are gone from the database, the customers have payment confirmations, and reconciling that manually is a bad day. Check first.

Restore WordPress backup to staging, not to production

A restore that fails halfway leaves you worse off than the original problem, because now the site is neither in its broken state nor its restored one. Restoring to a staging environment first removes that risk entirely.

The sequence is: restore the backup to staging, confirm the site loads, check the specific thing that broke is now working, spot-check recent content, then promote staging to production or repeat the restore on production knowing it works. On a site with real traffic this is worth the extra fifteen minutes every time.

Files and database are different problems

Database-only restore

Appropriate when content is corrupted, a bad import ran, or a plugin mangled its settings, but the files are fine. Faster and lower risk than a full restore. Be aware that plugin settings, users, posts and WooCommerce orders all live in the database, so a database restore rolls all of them back together.

Files-only restore

Appropriate when a plugin or theme update broke the site, or when files have been modified by an attacker. Keeps all content and orders intact because the database is untouched. This is usually the correct restore after a failed update, and restoring the whole site including the database is a common overreaction.

Full restore

Appropriate after a serious compromise, a catastrophic failure, or when you genuinely do not know what changed. It is the biggest hammer and it rolls back everything, so it deserves the most careful check of what falls in the gap.

After the restore

• Confirm the front end loads and the specific broken thing now works
• Log into wp-admin and check plugin and theme versions are what you expect
• Flush every cache: the plugin cache, the host cache, and the CDN
• Check permalinks resolve, and re-save permalink settings if they do not
• Verify forms submit and, on a shop, that checkout completes
• Confirm scheduled tasks are still running rather than silently stopped

That last point catches people out. WP-Cron entries live in the database, and a restore can bring back stale schedules or lose recently added ones. Backups, in particular, sometimes stop running after a restore, which means the site is unprotected precisely when you are most likely to need protection again.

Why untested backups fail

The uncomfortable truth about backups is that a large proportion of them do not restore. The failure modes are consistent: the backup plugin hit a PHP timeout partway through a large database and wrote an incomplete archive; the destination filled up; credentials expired and the schedule silently stopped; or backups have been running perfectly for two years to a folder on the same server that has now been wiped.

None of these produce an alert, because the plugin believes it succeeded. You find out during an incident, which is the worst possible moment to learn something new about your infrastructure. The only reliable way to know a backup works is to restore it somewhere and check, on a schedule, before you need it.

What good looks like across a portfolio

• Incremental backups so large sites do not time out mid-archive
• Off-site storage in a different failure domain from the site itself
• A restore point taken automatically before every update
• Scheduled restore testing that boots the backup and confirms it works
• Retention long enough that a problem discovered late is still recoverable
• Visibility across every site of which backups have never been restore-tested