The site is down. You have backups — you set them up, you have seen the emails. You start the restore and it fails, or it finishes and the site is still broken, or it finishes and the site is now three months out of date.
A WordPress backup restore failed is not a message you see on a calm afternoon. The discovery always happens at the worst possible moment, and it is the single most preventable disaster in website maintenance.
Why restores fail
A backup not restoring almost always comes down to one of five things, and four of them happen long before the day you try.
The backup was never complete. Many backup plugins run in stages and give up quietly when the server stops them partway. The email says the job finished. The archive is missing half the uploads folder. Nothing warns you, because from the plugin’s point of view it stopped normally.
The database saved but the files did not, or the other way round. A WordPress site is both, and they have to match. A database restored over the wrong set of files produces a site that half works, which is more confusing than one that does not work at all.
The backup lives on the same server as the site. This is the most common arrangement and the least useful one. It protects you from a bad update. It protects you from nothing else — not a suspended account, not a compromised server, not a host with a hardware failure.
The restore ran out of resources. Restoring is heavier than backing up. On shared hosting the process is frequently killed midway, leaving a database half-imported — a state considerably worse than where you started.
The backup is older than you think. The schedule stopped weeks ago, silently, and nobody checked. This is common enough to deserve its own explanation: see WordPress cron not running, which stops backups without producing an error anywhere.
Test the restore before you need it
This is the only part of this article that genuinely matters. An untested backup is a hope with a filename.
Restore a WordPress backup somewhere that is not your live site — a staging environment, a subdomain, a local copy. Then check four things: the homepage renders, a page deep in the site renders, the contact form sends, and the most recent content you remember publishing is present.
That last check is the one that catches a stale schedule. A backup that restores perfectly to a state from six weeks ago has failed at its job, and only a restore will tell you.
Once a quarter is enough for most sites. It takes half an hour and it converts a hope into a fact.
If the restore has already failed
- Stop and take a copy of the current broken state, however bad it is. A half-restored site still contains data, and overwriting it again can destroy what remains.
- Look for other copies. Your host almost certainly keeps its own backups on a separate schedule, often for a week or more, and many people forget these exist. Ask before assuming.
- Try an older archive. A backup from a week earlier that restores cleanly beats a recent one that does not.
- Restore the pieces separately. Files first, confirm they are intact, then the database. Doing them together is what fails; doing them in sequence often works.
- If the database import keeps dying, it is usually a resource limit rather than a corrupt file. Importing through the command line rather than a web interface avoids the timeout that is killing it.
The three-two-one habit, without the jargon
Storage advice usually arrives as a slogan. Underneath it is a simple idea worth following: keep more than one copy, keep them in more than one place, and keep at least one somewhere entirely separate from the site.
In practice that is the plugin backup on the server, the host’s own backup, and a copy in cloud storage or on a machine you own. Each protects against a different failure. The server copy handles a bad update. The host copy handles you deleting something. The off-site copy handles the account itself going away, which is the case that ruins businesses.
Also keep more than one date. A single rolling backup overwritten nightly is no help against a problem nobody noticed for a fortnight, because by then every copy contains it. Several weekly versions cost very little storage and cover the slow failures.
What good looks like afterwards
Three changes prevent nearly all of this. Store backups somewhere other than the server they came from. Keep several versions rather than one rolling copy, so a problem that went unnoticed for a fortnight is still recoverable. And restore one on purpose, occasionally, so the first restore you ever perform is not the one that matters.
Our guide to backing up a WordPress website covers setting them up. Backups that are actually tested is the difference between having a backup and having a recovery.