How to Know If Your Backups Actually Work

Ask a business owner whether their website is backed up and the answer is nearly always yes. Ask where the backups are, how far back they go, and when one was last restored, and the confident answer becomes “I’d have to check.”

That gap is where sites get lost. Not because nobody made a backup, but because the backup that existed was on the same server that died, or was three months old, or was a database with no files, or had been silently failing since a plugin update. Backups are one of the few things in IT where you find out whether they work at exactly the moment it is too late to fix them.

Here are the five questions that tell you which kind you have.

1. Where are they stored?

If the backup lives on the same server as the website, it is not a backup. It is a copy that will disappear with the site when the disk fails, the server is compromised, or the hosting account is suspended. This includes backups in a folder like /wp-content/backups/, which many plugins create by default and which are also, incidentally, sometimes downloadable by anyone who guesses the URL.

A real backup is stored somewhere else: a different provider’s object storage (S3, Backblaze B2, Wasabi), the host’s separate backup infrastructure, or at minimum a different server. The test: if the hosting company vanished tomorrow, could you still get at the backup?

2. How often, and how far back?

Frequency should match how often the site changes. A brochure site that changes monthly can be backed up weekly. A site taking orders or form submissions needs daily at least, and the database more often than the files.

Retention matters more than people expect. A problem — a hack, a corrupted table, an accidental deletion — is often not noticed for days or weeks. If you keep seven daily backups and discover on day nine that something went wrong on day one, every backup you have contains the problem. Thirty days is a reasonable minimum; longer for anything with legal or financial records.

3. What is actually in them?

A WordPress site is two things: files (core, plugins, themes, uploads) and a database. Some backup tools take only the database by default. Some skip the uploads folder because it is large. Some skip files above a certain size. Any of those produces a backup that restores to a broken site.

Open a recent backup and look. Is wp-content/uploads/ there, and does it contain this month’s images? Is the database dump a reasonable size? Does it contain the tables you expect — including the ones added by WooCommerce, forms plugins, or anything else that stores its own data?

4. Are they still running?

Backup jobs fail silently. A plugin update changes a setting. Cloud storage credentials expire. The disk fills up and the job aborts. A cron job that was running on a server that has since been migrated no longer exists.

The tool should tell you when a backup fails, not only when one succeeds — and the notification should go somewhere a person will see it. Better: a monitoring check that alerts if no successful backup has completed in the expected window. Silence should be an alarm, not reassurance.

Check the last-run timestamp right now. If it is more than a day or two older than you expected, you have your answer.

5. Has anyone restored one?

This is the question that matters. A backup that has never been restored is an assumption. Restoring one is the only way to find out whether the archive is corrupt, whether the database dump is complete, whether the process works, and how long it takes.

Do it to a staging environment or a temporary subdomain, not production. Time it. Note what broke — there is usually something: file permissions, a hard-coded URL, a missing table. Write down the steps. Then you have a procedure instead of a hope.

Once every six months is a reasonable cadence. After any change to the backup tool, storage, or hosting, do it again.

The afternoon test

If you want to go from “I think we have backups” to “I know” in one sitting:

1. Find the backup tool and where it stores backups. If it is on the server, that is finding number one.
2. Look at the last five runs. Note the dates and whether any failed.
3. Download the most recent backup. Confirm it has both files (including uploads) and the database.
4. Restore it to a staging copy of the site. Time it. Check a few pages, an admin login, and a recent piece of content.
5. Write down what you found and what you’d have to do differently in a real emergency.

Most businesses that do this find at least one problem. That is the point: finding it on a quiet Tuesday costs an afternoon. Finding it after the server dies costs the site.

If this is not how you want to spend an afternoon

Backups stored off-server, retained for a sensible period, monitored for failure and restore-tested on a schedule are a standing part of our website management and managed hosting services. If you would rather check your own, items 6 through 8 on the Website & Infrastructure Health Checklist cover backups and recovery in the same terms as this article.