Is your WordPress backup real? How to test a restore in 15 minutes

The only way to know your WordPress backup is real is to restore it somewhere safe and check the result. In about 15 minutes you can take your latest backup, restore it to a staging site or a local copy (never over your live site), then confirm the home page loads, you can log in, recent content and orders are there, images display and forms work. If any of that fails, you have found the problem on a quiet afternoon rather than in the middle of an emergency.

I treat untested backups as unknowns. Below is the routine I use, along with the most common reasons backups turn out to be useless.

Why backups fail when you need them

Backups usually do not fail dramatically. They fail quietly, in ways you only discover during a restore:

• Files but no database (or the reverse). Your theme and images are there, but every page, post, user and order lives in the database.
• Incomplete archives. The backup timed out halfway on a large site, and the zip file is missing the uploads folder.
• Stored on the same server. If the server fails or the hosting account is compromised, the backups go with it.
• Too old. The last successful backup was months ago because a storage connection expired and nobody noticed the error emails.
• Locked to the old host. Some host backups can only be restored on that host's own platform, which does not help if you need to move.
• Nobody knows how to restore it. The plugin was set up years ago and the person who chose it has moved on.

What you need before you start

• Your most recent backup, downloaded or accessible from your backup plugin, host or cloud storage.
• Somewhere safe to restore it. One of:
  • A staging site from your host. Many hosts offer one-click staging in the control panel.
  • A local WordPress environment on your computer, using a free tool such as Local or similar.
  • A spare subdomain on your hosting, such as restore-test.yourbusiness.co.uk, with a blank WordPress install.
• The restore method that matches your backup: the same backup plugin, your host's restore tool, or manual access to files and database.

One important warning: do not test by restoring over your live site. If the backup turns out to be broken, you will have replaced a working site with a broken one.

The 15-minute restore test

Step 1: check the backup itself (2 minutes)

Look at the backup before restoring anything:

• What date and time was it taken?
• Does it contain both files and a database? Database backups are often a .sql or .sql.gz file, or a clearly labelled part of the archive.
• Is the file size roughly what you would expect? A backup of a site with years of images that weighs only a few megabytes is suspicious.
• Where is it stored? Note whether a copy exists off the server.

Step 2: restore to your test location (5 to 8 minutes)

Follow the method your backup tool provides:

• Backup plugins: most popular backup and migration plugins can restore or import a backup onto a fresh WordPress install. Install the same plugin on the test site, upload or connect to the backup, and run the restore.
• Host backups: many hosts let you restore a backup to a staging environment rather than live. Look for a "restore to staging" or similar option.
• Manual backups: upload the files, create a new empty database, import the .sql file through phpMyAdmin or similar, then update the database name, user and password in wp-config.php.

Because the test site lives at a different address, the restore tool may offer to replace the old domain with the new one in the database. Accept that if offered. If you restore manually, you may need a search-and-replace tool that handles serialised data safely, so links and settings point at the test address.

Step 3: stop the copy contacting real people (1 minute)

A restored copy is a fully working site. Before you click around:

• Make sure search engines are discouraged: in Settings, then Reading, tick the option to discourage search engines from indexing the site.
• If it is an online shop, put payment gateways into test mode or disable them.
• Consider an email-blocking or email-logging plugin so the copy does not send real customer emails, for example order notifications or newsletters.

Step 4: check the result properly (4 minutes)

Work through this list on the restored copy:

1. The home page loads without errors and looks like the live site.
2. You can log in to the WordPress admin with your normal credentials.
3. Recent content is there. Find your most recent post, page edit or product change and confirm it appears. This tells you how up to date the backup really is.
4. Images display on a few pages, including older ones. Missing images usually mean the uploads folder was not backed up fully.
5. Plugins and theme are active and settings look correct, such as menus, widgets and page builder layouts.
6. Key data is present. For a shop, check recent orders and customers. For a membership or booking site, check recent sign-ups or bookings.
7. Forms submit on the test site, even if you are only logging the emails.

Step 5: write it down and tidy up (1 minute)

Record the date, which backup you tested, how long the restore took and anything that failed. Then delete or password-protect the test copy, as it contains the same data as your live site, including customer details if you have them.

What to do if the test fails

A failed test is good news in disguise: you have found the problem while the live site is still fine. Common fixes:

• Missing database or files: check the backup settings and make sure both are selected, then run a fresh backup and test again.
• Backup too large or timing out: exclude cache folders and old backup archives from the backup, or ask your host about limits. Some plugins can split backups into smaller parts.
• Out-of-date backups: check the schedule, reconnect any cloud storage that has expired, and make sure failure notifications go to an inbox someone reads.
• No off-site copy: connect the backup tool to cloud storage, so you always have at least one copy away from the server.

How often should you test?

For most small business sites, a full restore test every three months is a sensible rhythm, plus an extra test whenever you change host, backup plugin or storage location. Busy online shops, where losing even a day of orders would hurt, may want to test more often and back up more frequently. A useful rule of thumb is to match the backup frequency to how much data you could bear to lose: if a day of orders is too much, daily backups are not enough.

The aim is not perfection. It is simply knowing, rather than hoping, that you can get your site back. The WordPress security course covers backup strategy, off-site storage and full disaster recovery in more depth.

Questions people ask

Are my hosting company's backups enough on their own?

They are a useful safety net, but it is wise to keep your own backup too, stored somewhere independent of the host. Check how long the host keeps backups, whether you can download them, and whether restoring them costs extra.

Can I test a restore without a staging site?

Yes. A free local WordPress tool on your computer works well, as does a blank WordPress install on a spare subdomain. The key is never testing by restoring over your live site.

How many backups should I keep?

Keep several, not just the latest. Hacks and mistakes are often noticed days or weeks later, so having older restore points gives you a clean version to go back to. Check your storage limits and retention settings.