Start with one question: did a single restore point fail, or do all of them fail the same way? If one archive is broken, use a different one. If every backup produces the same errors, the archives are fine and the site was already damaged when they were taken. Those two situations need opposite responses.
Almost every guide on this treats a failed restore as one problem with one list of fixes. It is two problems, and telling them apart takes about a minute.
This article assumes your site is down or broken right now. Prevention is at the end, where it belongs.
First question: one restore point, or all of them?
Try a second restore point, ideally from a different week. That single test tells you which situation you are in.
If the second one works, the first archive was damaged. Corruption happens during creation, during transfer, or in storage. You have lost whatever changed between the two dates, which hurts, but you have a site.
If the second one fails the same way, stop restoring. Working through the list fixes nothing here. Something upstream is producing broken backups, or your database already carried the damage before any of them ran.
That second case is the one people get stuck in. One agency described having fifteen days of restore points available and every single one producing the same database errors, missing tables and broken plugin data. Fifteen attempts, fifteen identical failures.
If every restore point fails the same way
The backups are doing their job. That is the uncomfortable part.
A backup is a copy, not a validator. It never checks the health of your database before preserving it. If tables had already crashed, or a plugin had already written broken data, every nightly backup faithfully captured that damage. Restoring gives you back exactly what you had, including the parts that no longer worked.
So the question changes from “which backup works” to “when did this start.” Two things narrow it down.
Look for the oldest restore point you have. If a backup from thirty days ago restores cleanly and yesterday does not, the damage happened somewhere in between, and something in that window caused it.
Check whether the backup process itself has been failing. Open your backup plugin’s logs rather than its dashboard. The dashboard shows a green tick. The log shows what actually happened, and it is where truncated jobs leave their evidence.
If the oldest available backup also fails, the damage predates your entire retention window. At that point the archives are not the problem to solve, and the salvage section below is where to go.
Why your plugin said the backup succeeded
This is the part that makes owners feel stupid, and they should not. A completed backup is not the same as a working backup, for three reasons.
Archive checksums do not verify what is inside. ZIP and TAR checksums confirm the archive structure is intact. They do not confirm the compressed data within it will decompress correctly. An archive can pass every validation your plugin runs and still fail to restore.
Backups abort quietly. One documented support case shows a backup log ending with a note that the job aborted after repeated failures to progress. The owner had no idea until restore day, and nobody could recover the incomplete archive. The dashboard had shown a backup.
Backup jobs hit server limits. On a large site, the process runs out of PHP memory or execution time partway through. What you get is a file with a plausible name and size, missing tables nobody noticed were absent.
The uncomfortable rule underneath all three: the only proof a backup works is a restore that completed. One agency guide reports that fewer than 5% of WordPress owners have ever tested a full restore. The exact figure is one source’s estimate, but the direction is clearly right. Almost every failed-restore story starts with someone who believed they were covered.
What your error message actually means
Match what you are seeing to what it usually indicates.
| Error | What it usually means |
| “This database backup is missing core WordPress tables” | The backup is incomplete. That archive is unusable |
| “Unable to find any tables when scanning the database backup” | The archive is corrupt or was never finished |
| Error establishing a database connection after restoring | Credential or table prefix mismatch, or the import did not finish |
| “One or more database tables are unavailable” in wp-admin | Partial import, or genuinely crashed tables |
| MySQL error 1064 | A syntax error inside the backup file itself |
| Import stops partway with no error | The server’s max_allowed_packet limit |
| Site loads but content is scrambled | Corrupted serialised data in wp_options or wp_postmeta |
The “missing core tables” message is the most common and the most final. WordPress.org support threads carry several documented cases where the answer was simply that the archive cannot produce a working site. There is also a thread on verifying backup integrity that shows what an aborted job looks like in the log. If you see this error, move to a different restore point rather than trying to repair the file.
That last row is worth a note. Serialised data breaks when someone search-replaces URLs with a plain text tool instead of a serialisation-aware one. The result looks wrong but loads fine, which owners usually misdiagnose as a theme problem.
What you can still salvage
If no restore point works, a partial backup is rarely worthless. This is the part almost no guide covers, and it is where a total loss becomes a bad week instead.
Even an archive missing several tables usually still contains wp_posts and wp_postmeta. That is your content: every post, page, and custom field.
Work through it in this order.
- Open the SQL file in a text editor and search for CREATE TABLE to list what actually survived. This takes two minutes and tells you what is recoverable before you spend hours.
- Set up a clean WordPress install on a staging site, matching your original table prefix.
- Import only the intact tables. Posts and postmeta first, then anything else that survived the check.
- Rebuild the rest by hand. Users, settings and plugin configuration live in the tables most likely to be missing. Rebuilding them is tedious, and tedious is not the same as lost.
- Check your files separately. If the database failed but files are intact, wp-content/uploads still holds every image you have ever uploaded, and your theme and plugin files are still there.
Two commands worth running if you have WP-CLI access. wp db check reports table integrity, and wp core verify-checksums confirms your core files match the official distribution. If core files are altered, our guide to replacing WordPress core covers the safe way to do it.
One honest note. Sometimes the answer is that the data is gone. If no restore point contains your content and your files are also lost, no technique in this article recovers it, and continuing to try costs you time you could spend rebuilding.
What to check after a restore that appears to work
A homepage that loads is not verification. A restore point can predate a change to your payment gateway, CRM or booking system. Credentials and webhooks then stop syncing while the front end looks perfect.
Run this list every time:
- Log in as an administrator, then as a customer or subscriber
- Complete a test checkout if the site sells anything
- Submit every form and confirm the notification email arrives
- Run a search, open an archive page, load a paginated list
- Check every integration: payments, CRM, email platform, booking
- Compare post and user counts against what you expect
- Re-save your permalink settings if any URL returns a 404
The store dimension deserves its own line. Restoring a backup erases every order placed since that backup ran. On a WooCommerce site backed up nightly, restoring at 4pm can delete a day of orders you have not fulfilled. Export orders before restoring where you still can.
One more rule applies after a security incident. A backup taken after the breach still contains the malware. Confirm the restore point predates the compromise, and follow our malware removal guide rather than assuming a restore cleaned the site.
How to make sure this never happens again
Two habits, and only one of them is the obvious one.
Test a restore on a schedule. Quarterly is enough for most sites. Restore your most recent backup to staging, run the verification list above, and note what broke. That single exercise converts “we have backups” into “we can recover.” Those are not the same claim.
Keep backups outside the site’s blast radius. A backup stored on the same server dies with the server. Off-site storage, a retention window longer than the time it typically takes to notice a problem, and a copy your host does not control.
Beyond that, check your backup logs occasionally rather than the dashboard, and confirm archive sizes look consistent month to month. A backup that suddenly shrinks by half is telling you something. Our WordPress backup guide covers the setup side properly, and our care plans include restore testing because a backup nobody has tested is a hope rather than a plan.
Key takeaways
When a WordPress backup restore failed, test a second restore point before doing anything else. One broken archive and every archive failing identically are different problems with opposite responses.
If all of them fail the same way, the backups preserved damage that already existed. Look for your oldest restore point and check the backup logs rather than the dashboard, because a green tick and a complete archive are not the same thing.
If nothing restores, check what the SQL file actually contains before assuming total loss. Posts and postmeta usually survive, and uploads are held separately in your files. And after any restore that appears to work, verify logins, checkout, forms and integrations rather than the homepage alone.
Frequently asked questions
Why did my WordPress backup restore fail?
Usually because the archive is incomplete. Backup jobs abort quietly when they hit PHP memory or execution limits, producing a file that looks normal but is missing database tables. Corruption during transfer or storage causes the same result. Server limits during import, such as max_allowed_packet, can also stop a restore partway.
All my backups have the same error. What does that mean?
That the archives are working and the source was already damaged. A backup copies your database rather than validating it, so pre-existing corruption gets preserved in every subsequent backup. Look for your oldest available restore point and check when the problem began, rather than working through the newer ones.
Can I recover anything from a corrupted backup?
Often yes, partially. Open the SQL file in a text editor and search for CREATE TABLE to see which tables survived. Posts and postmeta usually do, which means your content is recoverable even when users and settings are not. Files, including every uploaded image, are stored separately from the database.
Why did my backup plugin say the backup was successful?
Because plugins report that a job finished, not that the result is restorable. Archive checksums verify structure rather than the compressed contents, and jobs that abort partway can still leave a plausible-looking file. Check the backup log rather than the dashboard, since truncated jobs record the failure there.
How do I know a backup will work before I need it?
Restore it. Take your most recent backup, restore it to a staging site, then log in, complete a test transaction, submit a form and check your integrations. Doing this quarterly is the only reliable proof. Archive size consistency and clean backup logs are useful signals, but neither one is verification.
Need someone to look at it before you make it worse?
A failed restore is the moment when the next decision matters most, and it is easy to destroy recoverable data while trying to save it. If the site is down and you are not sure what is safe to try, stop and send it to us before the next attempt. Survyc is an AI-first digital agency that recovers broken WordPress sites for agencies and businesses, and we will tell you honestly what is recoverable and what is not. Our guide to what a WordPress repair costs explains how we scope it. Tell us what happened or email info@survyc.com.
