How to Fix a Failed WordPress Restore from Backup

You’ve been there. You click “restore”, wait for the progress bar, and then—nothing. Or worse, a white screen. Or a database connection error. A failed WordPress restore from backup is stressful, but it’s almost always fixable. In this guide, I’ll walk you through the exact steps to diagnose and fix the problem, whether you’re restoring via a plugin or doing it manually.

What Causes a WordPress Restore to Fail?

Restores fail for a handful of common reasons. Knowing them helps you fix the issue faster. The main culprits include:

• Incomplete or corrupt backup files – The backup might have failed silently, leaving you with a partial file.
• File permission errors – If your server doesn’t allow writing files, the restore won’t complete.
• Database import errors – A SQL file that’s too large or has syntax issues can halt the restore.
• Plugin or theme conflicts – After restore, a recently activated plugin might break the site.
• PHP execution time limits – Large backups get cut off if your server’s timeout is too low.

I’ve seen all of these, and each has a straightforward fix. Let’s go through them step by step.

First: Check the Error Log

Before you try anything else, look at your PHP error log. This is the fastest way to know what went wrong. If you use cPanel, find the error log under “Metrics” or “Logs.” For command-line access, check /var/log/ or your hosting panel.

A common error is “Allowed memory size exhausted” – that means you need to increase PHP memory limit. Another is “Maximum execution time exceeded” – increase max_execution_time in php.ini. The error log tells you exactly what PHP choked on.

If your site shows a white screen, enable WP_DEBUG in wp-config.php: define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true);. Reload the site, then check the wp-content/debug.log file.

Verify Your Backup Files Are Complete

A corrupt or incomplete backup is the most common cause of a failed restore. If you used a plugin like UpdraftPlus or BackupBuddy, the backup might have been split into multiple files. Make sure you have all parts. Check the file sizes: a typical WordPress backup can range from a few MB to several GB. If your backup is suspiciously small (like 1 KB), it’s likely empty.

I recommend keeping copies of your backup both locally and in the cloud. For more on backup strategies, check out my guide on Manual vs Automated WordPress Backups. It covers how to avoid corrupt files in the first place.

Fix Database Import Issues

If the database restore failed, your site might show a “Error establishing a database connection” message. The fix is often manual.

Using phpMyAdmin

1. Log into phpMyAdmin (usually accessible via cPanel or your hosting panel).
2. Select the database for your WordPress site. If the old tables are still there, drop them first.
3. Go to the “Import” tab, choose your SQL backup file, and click “Go.” For large files, check “Partial import” and set “Number of records (queries) from 1 to 1000” to avoid timeouts.

Using WP-CLI

If you have command-line access, WP-CLI makes it easy: wp db import your-backup.sql. This often handles large imports better than phpMyAdmin.

For a deeper understanding of the database, read the Beginner’s Guide to WordPress Database Backup.

Note: Always change the table prefix in wp-config.php if the backup used a different one. Otherwise, the tables won’t be recognized.

Reset File Permissions and Ownership

After a restore, file permissions sometimes get reset incorrectly. Directories should be 755, files 644. If they’re wrong, WordPress can’t read or write files, causing errors.

From the command line, run these commands inside your WordPress root:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

For ownership, ensure the files are owned by your web server user (often www-data or nobody). Use chown -R www-data:www-data .

If you don’t have SSH access, many hosting panels let you reset permissions via the file manager. Select the root WordPress folder, choose “Change Permissions,” and apply the standard values.

Deactivate Plugins and Themes via Database

Sometimes the restore itself works, but a plugin or theme that was active in the backup causes a conflict. If you can’t access the admin area, you can deactivate everything directly in the database.

1. Access phpMyAdmin and open your WordPress database.
2. Find the wp_options table (or whatever your table prefix is).
3. Look for the row with option_name = active_plugins. Edit it and replace the value with a:0:{} (this tells WordPress there are no active plugins).
4. For the theme, find the row with template and stylesheet in wp_options. Set them to a default theme like twentytwentyfour.

After this, log in to wp-admin and reactivate plugins one by one to find the culprit.

Manual Re-Upload of WordPress Core Files

If the restore left your core WordPress files missing or corrupt, the easiest fix is to download a fresh copy of WordPress from wordpress.org, unzip it, and upload everything except the wp-content folder and wp-config.php. Overwrite the old files.

This replaces any corrupted core files without touching your themes, plugins, or uploads. After that, access /wp-admin/upgrade.php to update the database if needed. This step alone fixes many “white screen of death” scenarios.

When All Else Fails: Start Fresh and Import

If none of the above works, you might be dealing with a severely corrupted backup. In that case, install a fresh WordPress site on a new database, then use the WordPress Importer tool (Tools > Import) to bring in your content from a WXR export file. If you have a backup of your uploads folder and database, you can manually copy uploads into /wp-content/uploads/ and import the SQL into the new database. This is more work but often recovers the data when a full restore fails repeatedly.

To prevent future restore failures, read How to Back Up a WordPress Site Before Migration – it covers best practices for creating reliable backups.

Quick Comparison Table: Common Fixes

Symptom	Likely Cause	Recommended Fix
White screen after restore	PHP memory limit or plugin conflict	Increase memory limit, deactivate plugins via DB
Database connection error	Incomplete SQL import or wrong credentials	Re-import manually via phpMyAdmin, check wp-config.php
404 errors on pages	Permalink structure not restored	Go to Settings > Permalinks and click “Save Changes”
File upload errors	Wrong folder permissions	Set 755 on wp-content/uploads
Restore stops halfway	PHP execution timeout	Increase max_execution_time in php.ini

A failed restore is frustrating, but it’s rarely permanent. Start with the error log, verify the backup, and work through the fixes above. Most of the time, you’ll be back online in under an hour. And next time, schedule regular backups with multiple destinations—that way you always have a fallback.

Frequently asked questions

Why did my WordPress restore fail with a white screen?

A white screen usually indicates a PHP error, such as memory limit exhaustion or a plugin conflict. Check your PHP error log for details. Increase memory limit in wp-config.php or deactivate all plugins via the database to isolate the issue.

How do I restore a WordPress database manually after a failed restore?

Use phpMyAdmin or WP-CLI. In phpMyAdmin, drop existing tables, select the target database, and import the SQL backup file. For large files, enable “Partial import” with 1000 queries per request to avoid timeouts.

What should I do if my backup file is corrupted?

If you have another copy from a different storage location, use that. Otherwise, you may need to start fresh with a new WordPress installation and manually import content from the most recent working backup you have.

Can a plugin conflict cause a WordPress restore to fail?

Yes. If a plugin was active in the backup and conflicts with the current server environment, it can break the site after restore. Deactivate all plugins via the database by setting the active_plugins option to a:0:{} in phpMyAdmin.

How do I fix “Error establishing a database connection” after a restore?

This means the database credentials in wp-config.php don’t match the restored database. Verify database name, username, password, and host. If the restore used a different prefix, update the $table_prefix in wp-config.php accordingly.