Most people find out their backups were broken at the exact moment they need them. The site is down, the pressure is on, and the file that was supposed to save the day turns out to be 90KB of nothing, or a database with no uploads folder, or a restore that errors halfway and leaves the site worse than before.
This is not rare. It is the normal outcome of a system nobody checks.
Why backups fail without telling you
A WordPress backup is several separate jobs pretending to be one. Export the database. Archive the files. Compress it. Upload it somewhere. Any of those can fail on its own while the others succeed, and most tools will still log something that looks like completion.
The usual culprits:
- Timeouts. The site grows, the database gets bigger, and one day the export runs past the server's execution limit. The job stops mid-table. You now have a partial SQL file that looks like a real backup because it has a sensible file size.
- Expired credentials. The connection to Dropbox, Drive or S3 needs reauthorising. The token lapses, uploads start failing, and the notification goes to an email address nobody reads.
- Disk space. The server fills up, often with old backups, and new ones cannot be written. Ironic, common, and completely silent.
- Exclusion rules. Somebody excluded wp-content/uploads years ago to keep the file small. The backup restores perfectly and every image on the site is a broken icon.
- Cron that stopped running. WordPress cron depends on traffic or a server task. If it quietly stops, the schedule stops with it. The last successful backup is from March and nothing anywhere says so.
In every case the failure mode is the same: no alarm, no red banner, no phone call. Just an assumption that keeps being true right up until it is not.
The green tick lies
Backup plugins report on whether the job ran, not on whether the result is usable. Those are different claims. A job can complete, log success, and produce an archive that will not restore, because nothing in the process ever opens the file back up and checks.
Think of it like a fire alarm that reports "installed" instead of "working." Installed is not the question.
The fix: ignore the status page. Download your most recent backup file to your own computer right now. Look at the size. Open the archive. Confirm there is a .sql file that is not tiny, and a wp-content folder with your actual images inside. If you cannot do that in ten minutes, you do not know whether your backups work.
How to actually test a restore
Downloading and eyeballing the file is step one. A real test means restoring the whole thing somewhere and confirming the site loads. Never test by restoring over your live site. That is how a drill becomes an incident.
The safe version looks like this:
- Spin up a separate environment. A staging site, a subdomain, or a local install on your machine.
- Restore the backup into it, start to finish, the same way you would in an emergency.
- Load the homepage. Then load a blog post, a product page, and the checkout or contact form.
- Log into wp-admin. Check that users, orders and settings are there, not just pages.
- Click a few images. Broken images mean the uploads folder was never in the backup.
- Time it. Write down how long the whole thing took. That number is your real recovery time, and it is usually longer than people expect.
Then throw the test environment away. You are not keeping it, you are proving a point.
How often to test
Testing every backup is unnecessary. Testing once and calling it done is not enough, because the things that break backups, site growth, expired tokens, plugin changes, all happen over time.
Quarterly is a sensible rhythm for most sites. Four times a year is frequent enough to catch a job that has silently drifted, and rare enough that you will actually do it. Also test after anything structural changes: a host migration, a new backup plugin, a major WordPress or PHP upgrade, or a big jump in site size.
The fix: put a recurring quarterly reminder in your calendar titled "restore a backup to staging." If it is not on a calendar it will not happen, because nothing about the site is currently broken and there is always something more urgent.
Who is checking yours
Be honest about the answer. For most sites it is nobody, and that is not negligence, it is just that backup verification is invisible work with no deadline attached. It never feels urgent until the one day it is the only thing that matters.
This is why Up Speed tests restores quarterly on every plan, not just Starter. Backups run on a schedule, off-site, roughly four times a month with 30-day retention and one-click restore, and then we actually restore one and confirm it comes back. Most hosts never do that step at all, which is why so many people discover the problem the hard way.
If you would rather have someone verifying the safety net instead of assuming it, the Starter plan is $99 a month per site and includes the testing, not just the backups.