WordPress Backup Restore Failed: How to Recover Safely

When a WordPress backup restore fails, stop retrying it on the live site. Preserve the current files and database, then work out whether the restore failed while unpacking files, importing the database, or reconnecting WordPress to the restored site.

Repeated restore attempts can make recovery harder. A half-restored site may have old files with a newer database, a restored database with missing uploads, or plugin data that no longer matches the installed plugin files.

Protect the current site first

Before changing anything else:

1. Put the site into maintenance mode if visitors can still reach a broken version.
2. Download the current wp-config.php file and the full wp-content folder through SFTP or the hosting file manager.
3. Export the current database from the hosting panel or phpMyAdmin if it is still accessible.
4. Keep the failed restore files separate from the original backup.
5. Note the backup date and any newer orders, form entries, comments, memberships, or user registrations.

A usable WordPress restore usually needs both the database and the site files. The database stores posts, settings, users, and many plugin records. The files store uploads, plugins, themes, and configuration. WordPress.org’s backup documentation explains what a complete backup should include.

For WooCommerce, membership, LMS, booking, or directory sites, restoring an older database can remove records created after the backup. Ask the host or backup plugin vendor whether they can restore files only, recover selected tables, or help merge recent data before replacing the live database.

Read the restore error before trying again

Open the restore log in your backup plugin or hosting panel. The useful part is usually near the first failure message, not the final “restore failed” line.

Look for clues such as:

• The backup archive cannot be opened.
• The archive upload did not finish.
• The server ran out of disk space or inodes.
• PHP hit a memory limit, upload limit, or execution timeout.
• Files could not be written because of ownership or permissions.
• The database import timed out or lost connection.
• The restore finished, but the site redirects to the wrong URL.
• WordPress loads, but media, plugins, or the active theme are missing.

If the restore stopped partway through, do not assume the site is safe to keep using. Treat it as an unstable recovery state until the database, files, and configuration are checked together.

Confirm the backup is complete

Check the backup archive on your computer or in the backup plugin’s storage view. Do not extract it over the live site while you are still investigating.

A full file backup commonly includes:

wp-admin
wp-content
wp-includes

Some backup tools do not include WordPress core files and instead store wp-content, configuration files, and a separate database export. That can still be valid if WordPress core is reinstalled separately.

Find the database backup too. It may be a .sql, .sql.gz, .zip, or plugin-specific archive. A file-only backup cannot restore posts or settings. A database-only backup cannot restore missing uploads, themes, or plugins.

Compare the backup size with earlier successful backups. A sudden drop may mean the backup was interrupted or excluded important folders. If the archive will not open, download it again from remote storage before giving up on that restore point.

Check disk space and server limits

A restore often needs much more free space than the compressed backup size. The server may need room for:

• The uploaded backup archive
• Temporary extracted files
• Restored site files
• A database import
• A rollback copy made by the restore tool

Check disk and inode usage in the hosting panel. Remove old staging sites, obsolete backup archives, and cache files only after confirming they are not part of the restore you need.

If the backup plugin reports a memory limit, upload limit, or timeout, ask the host to raise the limit temporarily or perform a host-level restore. Large restores are often more reliable from the hosting panel because they do not depend on a browser tab or WordPress admin request staying open.

Check the database connection

Open wp-config.php through SFTP or the hosting file manager and check the database settings:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

Do not copy database credentials from an old server unless the restored database is actually on that old server. Managed hosts often use a private database hostname instead of localhost.

Also check the table prefix:

$table_prefix = 'wp_';

The $table_prefix value must match the restored database tables. If the restored tables use wp7x_ but wp-config.php says wp_, WordPress may act like a new installation even though the database contains your old content.

If phpMyAdmin is available, confirm that the expected WordPress tables exist and use the same prefix. Do not run a database repair just because a restore failed. Export the database first, and repair tables only when your host, phpMyAdmin, or database diagnostics identify actual table damage.

Restore files without overwriting configuration blindly

If you are restoring files manually, use SFTP or the host’s file manager and keep a copy of the current wp-config.php before uploading anything.

Do not replace a working wp-config.php with an older one until you have compared:

• Database name, user, password, and host
• Table prefix
• Authentication keys and salts
• Custom content directory settings
• HTTPS, proxy, or load balancer configuration
• Host-specific directives

Restore wp-content/uploads before spending time on missing media. If images are still missing after the uploads folder is restored, check whether the backup included the correct year and month folders.

Restore plugins and themes from the backup when their versions need to match the restored database. If the backup archive may be damaged or suspicious, clean copies from WordPress.org, the developer, or the marketplace account are usually safer for plugins and themes that do not store custom files inside their own folders.

Fix the site URL after a migration

If the restore was moved to a different domain, subdomain, or HTTPS state, WordPress may still point to the old address.

First check the normal places:

• In wp-admin, go to Settings > General and review WordPress Address (URL) and Site Address (URL).
• If you cannot access wp-admin, check whether your host provides a WordPress tools page for changing the site URL.
• If neither is available, inspect the home and siteurl rows in the wp_options table through phpMyAdmin.

Change only the URLs that are wrong. Use the final public address, including the correct https:// or http:// protocol.

Do not perform a raw text replacement directly on the SQL file for URLs inside content. WordPress and plugins may store serialized data, and ordinary search-and-replace can break it.

Check file permissions and ownership

A restore can upload the right files but leave them owned by the wrong server user. Common signs include failed updates, broken media uploads, or errors when WordPress tries to create files under wp-content.

Ask the host to correct ownership when possible. Do not make every file or directory world-writable to force the restore through. Use the official WordPress guidance on file permissions and keep permissions as restrictive as the host supports.

Also check whether security software, malware scanning, or immutable file rules blocked files during extraction. If a security tool must be paused, do it through the host or vendor and turn it back on as soon as the restore is complete.

Optional SSH check for site URLs

If you have SSH access and WP-CLI is already available, it can help with URL problems after the normal file, database, and hosting-panel checks.

Check the stored home and site URLs:

wp option get home
wp option get siteurl

Update them only if they are wrong:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

For a domain-wide URL change inside content, export the database first. Then use WP-CLI’s database-aware wp search-replace command with a dry run:

wp search-replace 'https://old.example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

Review the dry run carefully before repeating the command without --dry-run.

Test the recovered site before reopening it

Once the files, database, and configuration are aligned, check the site before turning off maintenance mode.

Test:

• The home page and several internal pages
• /wp-admin/ login
• Recent posts, pages, users, orders, or form entries
• Images from different upload years and months
• The active theme and required plugins
• Permalinks and redirects
• Contact forms, checkout, scheduled tasks, and email delivery
• PHP error logs and the browser console

Clear WordPress, plugin, server, and CDN caches only after the restored state is stable. Cached responses can make a successful restore appear broken, or keep serving content from before the restore.

Roll back or ask for help when the site is still inconsistent

Return to the pre-restore snapshot if records are missing, file and database dates cannot be matched, or each retry leaves the site in a different state. Do not keep experimenting on the only remaining copy.

Give the hosting provider or backup vendor:

• The restore point and approximate failure time
• The exact error message from the restore log
• Whether file extraction or database import failed
• The backup archive name and size
• The amount of free server space
• Any recent domain, hosting, PHP, or database changes

Ask them to preserve the current disk and database state before attempting another restore. When no complete backup exists, recovering the latest intact database and uploads separately is usually safer than repeatedly applying a damaged full-site archive.