How often should you test your WordPress backups?

Most WordPress websites have some kind of backup. The hosting provider makes one, a plugin makes another, and someone may have downloaded a copy at some point.

The uncomfortable question is not whether a backup exists. It is whether that backup can actually bring the website back when something goes wrong.

Backups fail more often than people expect. A file may be incomplete, the database may be missing, the media folder may have been excluded to save space, or the only copy may be stored on the same server that just failed. Usually nobody notices until the day the backup is needed.

The good news is that this is easy to prevent. A restore test, done calmly and on a schedule, tells you whether your backups work while there is still time to fix them.

This guide explains what a restore test is, how often to run one depending on the kind of website you have, what to check, and who should be responsible for it.

Why is a backup only useful if it restores?

A backup is a promise: if the website breaks, is hacked or is deleted, you can go back to a known good state.

That promise depends on several things being true at the same time:

• the backup includes all the files the website needs
• the backup includes the database, where pages, settings, users and orders live
• the backup is recent enough to be useful
• the backup is stored somewhere you can still reach if the server is unavailable
• someone knows how to restore it and has the access to do so

If any one of these is missing, the backup may look fine in a dashboard and still be unusable.

Common problems found during restore tests include:

• archives that stopped being created weeks ago without anyone noticing
• backups that contain files but no database, or the other way round
• media uploads excluded because the backup was too large
• backups encrypted with a password nobody remembers
• copies kept only on the same hosting account as the website
• restore procedures that only the original developer understood

None of these are unusual. They are simply invisible until someone tries to restore.

What is a restore test?

A restore test means taking a backup and actually restoring it somewhere safe, then checking that the restored website works.

It is not the same as:

• seeing a green tick in a backup plugin
• checking that a backup file exists
• reading the backup size in the hosting panel

Those are useful signals, but they do not prove the backup can rebuild the website.

A proper restore test is normally done on:

• a staging copy provided by the hosting company
• a separate test domain or subdomain
• a local copy on a developer's computer

It should never be done by overwriting the live website. The point is to test the backup without putting the real website at risk.

How often should you test your backups?

There is no single correct answer. The right frequency depends on how often the website changes and how much it would cost the business to lose recent data.

As a starting point, consider the following.

Brochure or informational websites

Websites that change a few times a month, with no orders or user accounts, can usually be tested less often. A restore test every few months, and after any major change such as a redesign, migration or hosting change, is a reasonable baseline.

Websites with forms, bookings or memberships

If the website collects enquiries, bookings, registrations or member data, the database changes more often. Testing more regularly, for example every month or two, helps confirm that recent data is captured.

WooCommerce stores and busy websites

Online stores change constantly: orders, customers, stock levels and payments. Here a monthly restore test is a sensible minimum, and many businesses prefer to check more often. It is also worth checking that the backup frequency itself matches the volume of orders. The guide on whether a WooCommerce store needs real-time backups covers that question in more detail.

After any significant change

Whatever the type of website, run a restore test after:

• moving to a new hosting provider
• changing backup plugin or backup service
• a major WordPress, theme or plugin update
• a security incident
• adding a large amount of new content or media

These are the moments when backup settings are most likely to change without anyone realizing.

What should you check after restoring?

A restored website that loads its homepage is a good start, but it is not enough. Check the parts that matter to your business.

Files and code

• the active theme loads with the correct design
• plugins are present and active
• any custom functionality still works
• there are no missing file errors

The database

• pages, posts and menus are present
• settings look correct, such as site name and language
• user accounts exist and you can log in with a test account
• recent content appears, not only older content

Media

• images display on pages and in the media library
• downloadable files, such as PDFs, are present
• recently uploaded images are included

Missing images are one of the most common signs that the wp-content/uploads folder was not included in the backup.

Recent orders and form entries

If the website takes orders or collects form submissions:

• check the most recent order in the restored copy
• compare its date with the time the backup was taken
• check that customer accounts and subscriptions are present
• check that stored form entries are included, if your form plugin stores them

This tells you exactly how much data would have been lost if this backup had been restored on the live website.

Where should backup copies be stored?

A backup stored on the same server as the website protects against some problems, such as a bad update. It does not protect against others, such as:

• the hosting account being suspended or compromised
• a server failure
• the hosting provider losing data
• an attacker deleting both the website and its backups

For this reason, at least one copy should be kept off-site, meaning in a separate location managed independently from the hosting account. This could be a dedicated backup service or cloud storage that the website itself cannot delete.

When testing, it is worth restoring from the off-site copy at least some of the time. That is the copy you will need in the worst scenario.

How long should backups be kept?

Retention means how far back your backups go.

Keeping only the last few days can be a problem. Some issues are noticed late:

• malware that has been present for weeks
• content deleted by mistake and only missed later
• a plugin that slowly corrupted data

A common approach is to keep frequent recent backups, such as daily copies for a few weeks, and fewer older ones, such as weekly or monthly copies for longer. The right retention depends on your business, storage and any legal obligations around customer data.

Remember that backups contain personal data if the website stores customer details. Older backups should be protected and deleted when no longer needed, in line with your privacy obligations.

Who is responsible for testing backups?

This is often the real gap. The hosting provider assumes the developer tests backups. The developer assumes the hosting provider does. The business owner assumes someone is doing it.

It helps to write down clearly:

• which systems create backups, and how often
• where each copy is stored
• who checks that backups are being created
• who runs restore tests, and how often
• who has the access needed to restore in an emergency
• where the restore instructions are kept

Hosting backups are useful, but many hosting providers describe them as a convenience rather than a guarantee. Read your hosting terms to understand what they actually cover.

If no one is clearly responsible, restore testing tends not to happen.

What are the most common mistakes?

• Trusting the dashboard. A successful backup notification does not mean the backup can be restored.
• Testing on the live website. Restoring over production to "see if it works" can overwrite real orders and content.
• Keeping only one copy. One copy in one place is a single point of failure.
• Forgetting the database or uploads. A backup of files alone, or the database alone, is not a complete website.
• Never checking the backup date. If backups silently stopped, the latest copy may be weeks old.
• No written procedure. Under pressure, nobody wants to work out the restore process from scratch.

What does good look like?

A healthy backup setup usually has:

• automatic backups at a frequency that matches how often the website changes
• at least one off-site copy
• retention long enough to recover from problems noticed late
• regular restore tests on a staging or local copy
• a short written note recording each test: date, backup used, what was checked, what was missing
• a named person or provider responsible for all of the above

It does not need to be complicated. It needs to be done consistently.

How D4Hub can help

D4Hub can help you turn backups from an assumption into something you have actually verified.

Depending on your website, D4Hub can help with:

• reviewing which backups exist and where they are stored
• checking whether files, database and media are included
• setting up an off-site backup copy
• running a restore test on a staging or local copy
• documenting a restore procedure your team can follow
• suggesting a backup frequency and retention that suits your website
• including backup checks in ongoing maintenance through D4Hub support plans

You can ask for support at any stage, whether you want a one-off check or regular testing as part of maintenance.

unzip -l backup.zip | grep "wp-content/uploads" | head
unzip -l backup.zip | grep "\.sql"

tar -tzf backup.tar.gz | grep "wp-content/uploads" | head
tar -tzf backup.tar.gz | grep "\.sql"

grep -c "CREATE TABLE" database.sql

wp db export test-site-before-import.sql
wp db import database.sql

wp search-replace "https://www.example.com" "https://staging.example.com" --dry-run

wp option update blog_public 0