A backup you haven't tested isn't a backup

Ask any business owner if they have backups of their website and the answer is almost always "yes". Ask them when they last restored from one, and you get silence, or a vague "I think the hosting company does it".

Both of those are the same answer: "I hope I have backups."

Here's the uncomfortable truth, and what to do about it.

Why untested backups fail

Backups break silently. Here are the real reasons we've seen backups not restore when they were needed:

• The backup job had been failing for eight months; nobody was reading the alert emails.
• The backup was there, but the automation used to restore it depended on a plugin that had since been removed.
• The database dump was truncated — the job ran out of disk halfway through.
• The backup file was 2GB of zeroes because a config change pointed it at an empty directory.
• The backup existed on the same server as the site, which was the server that got compromised.
• The backup format had changed between the tool used to take it and the tool used to restore it.
• Nobody remembered the encryption password.

None of these would have been caught by "do we have backups?" A test restore catches all of them.

What testing actually means

"Testing a backup" doesn't mean checking that the backup file exists. It means:

1. Take a recent backup.
2. Restore it to a staging environment — a separate server or local copy.
3. Confirm the site loads.
4. Confirm recent content is present.
5. Confirm users can log in.
6. Confirm any integrations that rely on the database work (orders, forms, subscriptions).

If all of those pass, you have a real backup. If any of them fail, you've found a problem while it's cheap to fix.

How often to test

For most businesses:

• Monthly test restores, automated where possible.
• Any time you change your hosting, CMS major version, or the backup tool itself — these are the exact moments things silently break.
• Any time you add a major new data dependency — a new e-commerce platform, a new CRM integration, a new custom plugin.

For businesses where downtime directly costs money (news sites, e-commerce at scale, membership communities during launches), test weekly. That sounds excessive until you have to restore one.

The 3-2-1 rule, briefly

The short version every IT person will quote: three copies of your data, on two different types of storage, with one copy offsite.

For a WordPress site that usually looks like:

• Live production database and files (copy 1, on your server).
• A nightly backup stored on the hosting provider's backup volume (copy 2, different storage on the same provider).
• A weekly or daily copy pushed to an entirely different provider — S3, Backblaze, a different hosting company (copy 3, offsite).

If you've only got copies 1 and 2, a single compromised hosting account can wipe everything.

What to do today

Two quick things:

1. Open your hosting panel or your backup tool and look at the log. When did the last backup actually run? When did the last one actually succeed?
2. Download a copy of your most recent backup. Right now. See if you can open it. That alone catches most of the silent failures.

If the answer to either is "I don't know where to look", that's worth sorting before you need to find out the hard way. We look after this for clients as part of every server we manage — daily offsite backups, monthly test restores, and a clear log that says the last restore worked.