Your backups are fine. Have you ever restored one?

Last issue was an emergency: 2 critical PHP flaws and an update that could not wait. Every urgent update raises the same question: if it breaks the site, can you get back? This one is about the file you hope you never need and have probably never checked.

Almost every WordPress site I look at has a backup running. A plugin, a host feature, something. There is a green tick somewhere and it has been ticking for months. The owner sleeps fine because of it. That is the problem. The green tick is not the safety net. The restore is the safety net and most people have never once performed one.

A backup you have never restored is a guess. You are guessing that the file is complete, that it is not corrupted, that it includes the parts you actually need and that someone knows how to put it back under pressure. You find out whether the guess was right on the single worst day, when the site is down, a client is calling and it is far too late to discover the file was only ever half the picture.

The 4 ways a backup quietly fails

They rarely fail loudly. They fail in ways nobody notices until the day of the restore.

It lives on the same server as the site. If the backup sits on the same hosting account, then a server that dies, an account that gets suspended, or a hack that reaches the whole box takes the backup with it. A backup that cannot survive the thing you are backing up against is not really a backup at all.

It only holds half the site. A WordPress site is 2 things. The database, which holds your posts, pages, settings and users, plus the files, which hold your uploads, theme and plugins. Plenty of backups quietly capture one and not the other. A database with no uploads restores to a site full of broken images. Files with no database restore to nothing you recognise.

It stopped weeks ago and told no one. The job runs, then one week it fails and the failure notice goes to an address nobody reads or straight into a spam folder. The dashboard still shows the last success, so everything looks healthy while the real backup is a month stale and getting staler.

Nobody has ever done the restore. This is the one that catches careful people. The backups are genuinely fine. The gap is that restoring them is a job no one has practised, so on the day it matters it takes hours of fumbling instead of 20 calm minutes and every hour the site is down is costing something.

If you take one thing from this issue, make it this: the first restore should happen on a quiet weekday onto a staging copy, not on the day the live site is down. That is the difference between 20 calm minutes and an afternoon of guessing.

The fix: prove it once, then trust it

You do not need a bigger backup plugin. You need one honest test and then a habit.

Start by finding out where the backups actually live. Not "we have backups", but the specific answer: which service holds them and is that somewhere other than the site's own server. If the only copy is on the same hosting account, fixing that is the single most valuable thing you will do this month. Off the server, or it does not count.

Then check what is inside one. Open the most recent backup and confirm it contains both the database and the uploads folder, not just one of them. If you cannot tell what is inside it, that is your answer and it is not a good one.

Then do the restore. This is the part everyone skips and the only part that proves anything. Restore your most recent backup onto a staging copy of the site (never over the live one) and see whether you get the whole site back. Time it. If it takes you an afternoon of guessing, you have just learned that on the real day it would have taken an afternoon of guessing and now you can shorten that before it costs you.

Then set the schedule you will actually check. Daily for a shop or a site that changes often, weekly for one that rarely moves, with the successful runs landing somewhere a human reads rather than a dashboard nobody opens. A backup you have restored once and verify occasionally is worth more than a perfect one you have never touched.

If you want the wider picture of what else is quietly at risk on the site, the Maintenance Risk Check runs through backups alongside the other things that only ever matter on a bad day and tells you which one to sort first. When you would rather the whole thing was simply handled and tested for you on a schedule, that is exactly what the care plans are for.

Each issue is written to stay useful after send day. This one lives in the archive, filed by topic, so you can pull it back the next time someone tells you the site is "definitely backed up".

How we can work together

Reply with who currently holds your backups and the last time anyone actually restored one and I will tell you whether you have a safety net or just a reassuring green tick.