Ask a site owner whether they have backups and most say yes. Ask when they last restored one and the answer is almost always never.
Those are different states, and the gap between them only becomes visible on the worst possible day. A backup that has never been restored is not a safety net. It is a belief about a safety net, and the belief is wrong more often than anyone expects: incomplete archives, missing databases, silent failures weeks old, and backups sitting on the same server as the site they are supposed to save.
This page is about closing that gap in an afternoon, and then keeping it closed.
Why untested backups fail, in four ordinary ways
None of these is exotic. Each one is common.
The job stopped running and nobody was told. A plugin update changed a setting, a cron schedule broke, the storage account filled up, or a token expired. The dashboard still shows the schedule; the files stopped weeks ago.
The database is missing. The single most damaging incomplete backup. Files alone look reassuring and complete, and they contain none of your posts, pages, settings, users or comments. All of that lives in the database.
The archive is corrupt or truncated. A backup that ran out of memory or timed out halfway can still produce a file that looks like a file. It will not open when you need it.
It is on the same server as the site. A backup stored inside the site's own hosting account survives a bad plugin update. It does not survive an account suspension, a hacked server, a hosting failure, or a deletion.
The first three are only detectable by trying. The fourth you can check right now.
Check one: does it exist, and when did it last run?
Open whatever makes your backups. This is either a plugin, a feature of your hosting control panel, or both.
Look for two things: the date of the most recent successful run, and whether the last few runs are marked successful rather than merely attempted.
If the most recent success is older than you expected, you have already found something worth fixing, and you have found it on a calm day rather than a bad one.
Note whether your host's backups and your own overlap. Many hosts take their own, on their own schedule, with their own retention period. That is useful and it is not automatically enough, because it lives with the host and is subject to the host's rules about how far back they keep it.
Check two: is the database in there?
Download one backup and look inside it.
A complete WordPress backup contains two distinct things: the files, and a database export. In the archive, the files show up as the familiar layout, wp-admin, wp-content, wp-includes and wp-config.php. The database shows up as a .sql file, or as several, sometimes compressed separately.
If there is no .sql file anywhere, your backup does not contain your content. That is the check most worth doing today, it takes five minutes, and it is the one that catches the failure people discover too late.
Check the size while you are there. A database export for a site with a few hundred posts is normally at least a few megabytes. A file measured in kilobytes usually means the export stopped early.
Check three: does it open?
Try to extract the archive on your own computer. If it opens cleanly and the folder structure looks like a WordPress site, the archive is intact.
If it will not extract, or extracts partially with errors, the backup is not usable and you have learned that before it mattered. That usually points at a timeout or a memory limit during the backup run, which is a solvable problem once you know it is happening.
Check four: restore it somewhere, which is the only real proof
The first three checks establish that a plausible backup exists. Only this one establishes that it works.
Restore into a staging copy, never over your live site. A restore overwrites, and practicing on the only copy you have is not practice. Setting up a staging site is a subject of its own and our guide to testing an update on a copy of your site first covers the same ground, because a staging site is the tool for both jobs.
Once restored, check five things rather than glancing at the home page:
- A recent post you remember writing appears with its content intact.
- The images on that post load, rather than showing as broken.
- You can log in with your normal username and password.
- Your settings survived: the site title, the permalink structure, the menus.
- Your plugins are present and their data is there, not just their code. A form plugin with no saved entries, or a shop with no orders, is a database that came across incompletely.
If all five hold, you have a proven backup and you know how long the restore takes, which is a number worth knowing before the day you need it.
Write down what you learned
Three things, in a note you can find under pressure:
Where the backups are. The exact service, the account, and how to log in. Not "in the cloud".
How long a restore takes. Measured, not guessed. This is the number that determines whether you attempt a restore during business hours.
What is not covered. Most backups exclude caches and temporary files, which is fine. Some exclude the uploads folder to save space, which is not, because that is every image on your site.
How often to re-verify
Once, thoroughly, then whenever something changes: after you switch backup plugin or host, after a major WordPress release, and after any change to where the backups are stored. Twice a year on a quiet site is a reasonable rhythm.
The important thing is that the first one happens. A verification you keep meaning to do provides exactly as much protection as no backup at all, and costs the same amount of storage.
Where this fits with everything else
This page is the reason the rest of this site's troubleshooting advice can be written honestly. Rolling back, isolating plugins, editing wp-config.php, removing a plugin that has been running for years: each of those is a reasonable step for someone with a proven restore, and a gamble for someone without one.
That is also why our pre-update checklist starts here rather than mentioning backups in passing, and why understanding what an update actually replaces is worth reading alongside it: knowing which files an update touches tells you what a restore has to put back.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. Nothing on this page is version-specific; the file layout and the file-plus-database structure of a WordPress site have been stable for many years. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19. No backup product is named or recommended anywhere on this page, deliberately.
