How to test website backups before the day you need one.

The short answer

To test website backups, check three things. First, open the storage itself and confirm that fresh backups are arriving, with sensible sizes, for both the database and the files. Second, restore one into a private copy of the site, never over the live one. Third, compare that copy with the live site: pages, images, forms, logins, and on a store the number of products and orders.

If you have never done all three, your backup is still unproven. Do it now, after any hosting or plugin change, and on a schedule a few times a year.

Why backups fail without telling anyone

A backup plugin’s settings page shows what you asked for. It does not show what actually happened. In September 2026 I moved more than twenty client websites onto my own server and then audited every WordPress site’s backups by looking in the storage, not at the plugin. Several had per-site backups that had quietly stopped landing, even though the backup plugin looked fine. Every one of them was still covered by the nightly whole-server backup. The per-site failures, and a few near misses, came from causes no screen reported:

• The schedule never changed. New backup times had been saved in the settings, but the scheduled job underneath still ran on the old timing, weeks apart or not at all.
• The job never ran. On one site the server task that drives WordPress’s scheduled jobs was failing silently, so nothing scheduled had run for more than a week.
• Half the backup arrived. An older plugin version could not upload large files to cloud storage. The database and plugin archives landed. The uploads archive, holding every image on the site, never did.
• The destination was gone. Several sites still sent their backups to storage on old hosting that no longer existed.

Even the whole-server backup had a gap: one night was missing from storage, because the schedule skipped the day reserved for a weekly run. It now runs every night.

None of this showed up as an error. All of it showed up the moment someone looked at the storage itself.

What a complete WordPress backup includes

A WordPress site lives in two places, and a backup that misses either one cannot rebuild the site. WordPress’s own backup guide makes the same point: you need both to restore a typical site.

• The database. Every page, post, setting, user, form entry, and on a store every product and order.
• The files. The wp-content folder above all: uploads (your images and documents), plugins and themes. Also wp-config.php and .htaccess, which hold settings a restore depends on.

The database changes every time someone orders, books or fills in a form, so it needs backing up most often. On the sites I host, each database is backed up daily with two weeks kept, and files weekly with four weeks kept, to Backblaze B2 cloud storage.

Where the backup lives matters as much as what is in it. A backup stored on the same server as the site disappears with the server. It needs to be somewhere else, ideally under an account the website itself cannot delete.

Step 1: Look in the storage, not the plugin

Log in to wherever the backups go, whether that is cloud storage, Google Drive, Dropbox or your host’s backup area, and look at the files themselves.

• Dates. Is there a database backup from the last day or two? Files from the last week or two?
• Every part. Most plugins split a backup into pieces: database, plugins, themes, uploads, other. A set missing the uploads piece is the most common half-backup.
• Sizes. A database backup of a few kilobytes on a site with hundreds of pages is a failure. The uploads archive should be roughly the size of your uploads folder.
• History. Are older copies kept, or does each new backup replace the last? One copy means a problem you notice late has already overwritten the good version.

If anything is missing, check the plugin’s log, the destination settings and whether WordPress’s scheduled jobs are running at all. WordPress’s auto-updates guide says to check Tools, then Site Health, for errors when scheduled tasks are not running.

Step 2: Restore to a private copy

Never test a restore on the live site. If the backup is bad, you have just replaced a working site with a broken one.

1. Make a place to restore into. A staging copy from your host, a subdomain with its own empty database, or a local install on your computer.
2. Restore the database and the files from the backup you are testing, not from the live site.
3. Change the address. The restored database still points at your live domain. WP-CLI’s search-replace command swaps the old address for the staging one and handles WordPress’s serialized data. Run it as a dry run first to see what it will change.
4. Keep the copy private. Turn on the Reading setting that asks search engines not to index the site, and put a password on the whole staging site so it never competes with the real one in Google.

If the restore fails at any step, you have learned the most valuable thing a backup test can teach you, on a day when nothing was on fire. Compare that with the day a plugin update breaks the site or a hack forces a restore, when there is no time to discover the backup is incomplete.

Step 3: Check the copy like a customer, then count

A restored site that loads its home page has not passed yet.

• Click through the main pages and look for missing images, which point straight at a missing uploads archive.
• Log in to the admin.
• Submit a form and confirm it records an entry.
• On a store, open products, add to cart and reach the checkout page (in test mode only).

Then count, because counts catch what your eyes skip. When I move a site between servers, nothing switches over until every file count and every database table’s row count match the original. The same standard works for a backup test: compare the number of published pages and posts, users, form entries, and on a store products and orders, between the restored copy and the live site. Numbers that differ by more than what happened since the backup was taken mean something did not come back.

How often to test website backups

Automated checks can confirm every day that new backups arrived with sensible sizes. A full restore test takes longer, so do it on a schedule and whenever something changes:

• after moving hosts or changing the backup destination
• after updating or replacing the backup plugin
• after a big change to the site, such as a store launch or a redesign
• a few times a year even when nothing changed

Keep a one-line record each time: the date, which backup, how long the restore took, and whether the counts matched. The first time you need a backup for real, that record is what tells you how long the site will be down.

What I do for the sites I host

After the September audit, every WordPress site on my server, most of them belonging to Louisville and Kentucky businesses, got the same setup, and each fix went to the cause:

• schedules re-registered so new settings actually take effect
• scheduled jobs on every site driven by a server task every five minutes, and the one that was failing replaced
• the backup plugin updated to a version that handles large uploads, with automatic updates on
• every site pointed at cloud storage, with the first backups confirmed in the bucket
• the whole server backed up nightly offsite on top of the per-site copies

The proof of each fix was the same as the test above: a fresh database file and a fresh uploads archive in storage, with the right sizes. That checking is part of my WordPress maintenance plans and every site on my managed WordPress hosting. The full story of the server move is in how I moved more than twenty sites to one server.

Frequently asked questions

Doesn’t my web host back up my site?

Many hosts keep backups, but ask three questions: how far back they go, whether they are stored off the server, and whether you can restore one yourself. Some keep only a few days on the same machine. A host backup is a good extra layer. It should not be your only one.

Is a backup plugin enough?

A plugin is the tool. The proof is in the storage and in a restore. Most of the failures I found in September 2026 were on sites with a backup plugin installed and set up.

How far back should my backups go?

At least two weeks of daily database copies and a month of weekly file copies covers most problems, including a hack or a bad update that nobody noticed for a few days.

What happens to orders placed after the last backup?

They are not in it. That is why a store’s database is backed up daily, and why restoring an old database over a live store should be the last resort, after exporting newer orders.

Can you test my backups if you did not build my site?

Yes. I restore your latest backup into a private copy, compare it with the live site and tell you plainly what came back and what did not.