WordPress Backup Not Restoring Properly - Troubleshooting

You have a disaster. Your WordPress site is broken, hacked, or corrupted.

You need to restore from backup.

You download your backup file. You're ready to recover.

And then one of these happens:

  • "Lost connection to MySQL server"
  • "Database error" or "couldn't import database"
  • "File too large" or "Max execution time exceeded"
  • Import finishes but site is completely broken
  • Only half the site restores, pages are missing
  • "Table already exists" errors
  • Restore completes but database is empty
  • Files extract but permissions are wrong

Your backup won't restore. You can't recover. You're still stuck with the broken site.

A client of ours got hacked. Their backup was 2GB. They tried restoring via phpMyAdmin. The import timed out at 1GB. They tried twice more, got the same error. Their backup was useless.

They thought their backup was corrupted. It wasn't. They just didn't know how to handle large backups.

Backup restoration failures are incredibly common and incredibly frustrating. You did everything right by backing up. You should be able to trust that backup. But then it fails and you panic.

The good news: Restore failures almost always have fixes. The backup is usually fine. The restoration process just needs adjustment.

Why Backups Fail to Restore

Understanding the cause tells you which fix to use.

  • File too large: Database or backup file exceeds server limits
  • Memory limit: Restoring requires more PHP memory than available
  • Execution timeout: Restoration takes longer than timeout allows
  • Database connection lost: Server drops connection mid-restore
  • Plugin conflicts: A plugin breaks the restore process
  • Charset/encoding issues: Database encoding doesn't match backup
  • Table prefix mismatch: Backup has different table prefix than target
  • File permissions wrong: Files restore but can't be executed
  • Corrupted backup: Backup file is damaged or incomplete
  • Search and replace issues: URLs updated incorrectly during restore

Step 1: Verify Your Backup File is Valid

Before trying to restore, confirm the backup isn't corrupted.

Check backup file size

  1. Download your backup file (if not already downloaded)
  2. Check the file size
  3. Compare to what your backup plugin says the size should be
  4. If actual size is much smaller, backup might be incomplete

Verify backup file type

Depending on your backup plugin, look for one of these:

  • .zip file: Compressed archive (most common)
  • .tar.gz file: Compressed tar archive
  • .sql file: Database dump only
  • .wpvault file: UpdraftPlus format

Test if the file is extractable

  1. On your computer, try extracting the backup file
  2. Use 7-Zip, WinRAR, or built-in extraction tool
  3. If extraction fails, backup file is corrupted
  4. If extraction succeeds, see what's inside

If backup is corrupted

Try to get an older backup.

  1. Check if your backup plugin stored multiple backup copies
  2. Most plugins keep 2-4 backups (UpdraftPlus, BackWPup, etc.)
  3. Try restoring from a backup from a week earlier
  4. If that works, restore and update from there

If you have no uncorrupted backups: Contact your hosting provider. Most maintain automatic backups on their server.

Step 2: Try a Different Restoration Method

Different methods work better for different situations. Try a different approach.

Method A: Use your backup plugin's restore function

This is the easiest method if your plugin has a restore button.

  1. If your backup plugin is still installed, use it to restore
  2. Go to your backup plugin's settings (UpdraftPlus, BackWPup, etc.)
  3. Find "Restore" button next to your backup
  4. Click "Restore"
  5. The plugin handles all the complexity
  6. After restore completes, check if site works

Why this works: Backup plugins know their own backup format. They handle large files, timeouts, and permissions automatically.

Method B: Use hosting's one-click restore

Some hosting provides one-click restore in their control panel.

  1. Log into your hosting control panel (cPanel, Plesk, etc.)
  2. Look for "Backups" or "Restore" section
  3. See if automatic backups are available
  4. Select a backup date
  5. Click "Restore"
  6. Hosting handles the entire process
  7. Site should be restored within minutes

Advantage: Hosting backups bypass all the limits that make phpMyAdmin fail. They have direct server access.

Method C: Restore via SSH command line

This works for large backups that phpMyAdmin can't handle.

  1. Connect via SSH
  2. Navigate to your WordPress directory
  3. If backup is .zip, extract it: 
    unzip backup-file.zip
  4. If backup is .sql, import it: 
    mysql -u username -p database_name < backup-file.sql
  5. Wait for import to complete (can take 30 minutes for large backups)
  6. Check if site loads

Why this works: SSH doesn't have the timeout or file size limits that phpMyAdmin has. Large backups import reliably.

Method D: Manual restore via FTP + database restore

  1. Extract backup file on your computer
  2. Connect via FTP
  3. Delete all files on the server
  4. Upload extracted files from backup
  5. Import database separately via phpMyAdmin

Why this works: Separating file and database restore avoids timeouts on either step.

Step 3: Check PHP Limits and Increase Them

PHP limits often prevent large backup imports. Increase them.

Check current PHP limits

  1. Log into wp-admin
  2. Go to Tools > Site Health
  3. Look for:
    • PHP memory limit (should be 256MB+)
    • Max upload size (should be 256MB+)
    • Max post size
    • Max execution time (should be 300+ seconds)

Increase limits via wp-config.php

  1. Connect via FTP
  2. Download wp-config.php
  3. Add these lines BEFORE "That's all, stop editing!": 
    define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '1024M' );
@ini_set( 'upload_max_filesize', '512M' );
@ini_set( 'post_max_size', '512M' );
@ini_set( 'max_execution_time', '600' );
  4. Save and upload
  5. Try restoring again

Increase limits via .htaccess

Add this to .htaccess (in WordPress root):

php_value upload_max_filesize 512M
php_value post_max_size 512M
php_value max_execution_time 600
php_value memory_limit 512M

If that doesn't work

Your hosting might have hard server limits. Contact them and ask to temporarily increase PHP limits for backup restoration.

Step 4: Disable Plugins Before Restoring

A plugin might interfere with restore process. Disable all plugins first.

Disable via FTP

  1. Connect via FTP
  2. Go to wp-content/plugins/
  3. Rename plugins folder to plugins-disabled
  4. Try restoring again
  5. If restore works, re-enable plugins one at a time

Common plugins that interfere

  • Backup plugins: If you have 2 backup plugins, they conflict
  • Security plugins: Wordfence, iThemes Security block database changes
  • Custom plugins: Any plugin with a __construct() that runs on init
  • WooCommerce: Complex database schema can cause import issues

Step 5: Restore Database via phpMyAdmin Properly

phpMyAdmin has specific settings for large imports. Use them correctly.

Prepare for large database import

  1. Go to phpMyAdmin
  2. Click on your database (not a table, the database itself)
  3. Click "Import" tab
  4. Look at "Location of the text file" section

Settings for large files

  1. Format: Set to "SQL" (if importing .sql file)
  2. Partial import: Leave unchecked
  3. Character set: Usually utf8mb4 (check if your old database was different)
  4. Skip existing tables: UNCHECK this (you want to overwrite)
  5. Don't show this menu again: Leave unchecked

Upload the backup file

  1. Click "Choose File"
  2. Select your .sql backup file
  3. Click "Open"
  4. Click "Go" to start import

If import times out

Use SSH command line instead (see Step 2 Method C).

phpMyAdmin has hard limits you can't overcome through the web interface.

If you get charset errors

Error: "Incorrect string value for column..."

  1. This means database encoding doesn't match backup
  2. The backup was likely utf8, target is utf8mb4 (or vice versa)
  3. Try importing with Character set: utf8 (not utf8mb4)
  4. If that fails, convert the backup file before importing

Step 6: Check Database Table Prefix

If your site has a non-standard table prefix, database import might skip tables.

What is table prefix?

By default, WordPress tables start with "wp_" (wp_posts, wp_users, etc.).

Some sites have custom prefix like "abc_" or "site123_".

Check what prefix your current site uses

  1. Open wp-config.php via FTP
  2. Look for line: $table_prefix = 'wp_';
  3. Note the prefix

Check what prefix your backup uses

  1. Extract backup .sql file
  2. Open it in a text editor
  3. Look for lines like: CREATE TABLE wp_posts or CREATE TABLE abc_posts
  4. Note what prefix is used

If prefixes don't match

Use Find and Replace in the .sql file.

  1. Open .sql in text editor
  2. Find and Replace: old_prefix_ → new_prefix_
  3. Save the file
  4. Upload and import

Or: Import as-is, then use phpmyadmin to rename tables after import.

Step 7: Check File Extraction and Permissions

Even if database restores, files might not be in right place or have wrong permissions.

Verify files extracted to correct location

  1. Connect via FTP
  2. Navigate to your WordPress root
  3. Check if wp-admin, wp-content, wp-includes folders exist
  4. Check if wp-config.php exists
  5. If files are in a subfolder (like "wordpress/"), move them up one level

Check file permissions

  1. Check wp-content/uploads folder: should be 775
  2. Check wp-config.php: should be 644
  3. Check .htaccess: should be 644
  4. Check all PHP files: should be 644
  5. Check all folders: should be 755

Fix file permissions via FTP

  1. Right-click file/folder
  2. Select "File Permissions" or "Properties"
  3. Change to correct value
  4. Apply recursively to all files inside

Fix via SSH

chmod -R 755 wp-content/
chmod -R 755 wp-admin/
chmod -R 755 wp-includes/
chmod 644 wp-config.php
chmod 644 .htaccess

Step 8: Run WordPress repair tools after restore

After restoring database, run WordPress repair to fix any issues.

Enable WordPress repair mode

  1. Open wp-config.php via FTP
  2. Add this line BEFORE "That's all, stop editing!": 
    define( 'WP_ALLOW_REPAIR', true );
  3. Save and upload

Run repair

  1. Visit yoursite.com/wp-admin/maint/repair.php
  2. WordPress scans database
  3. Fixes common issues automatically
  4. Shows report of what was fixed

After repair completes

  1. Remove the WP_ALLOW_REPAIR line from wp-config.php
  2. Save and upload
  3. This prevents unauthorized access to repair tool

Step 9: Search and Replace to Fix URLs

After restore, domain URLs might be wrong. Fix them with Search and Replace.

Why URLs break after restore

If you restored to a temporary domain (staging.example.com), all URLs in the database still point to the old domain (example.com).

Fix via plugin

  1. Install "Better Find and Replace" plugin
  2. Go to Tools > Better Find and Replace
  3. Find: http://oldsite.com → Replace: http://newsite.com
  4. Also do https variations
  5. Also do www and non-www variations
  6. Click Replace All
  7. Verify site loads correctly

If you can't access wp-admin to install plugin

Use SSH to run WP-CLI command:

wp search-replace 'http://oldsite.com' 'http://newsite.com'

Be careful with Search and Replace

Always test in a staging environment first. Search and Replace can break things if done wrong.

Step 10: Enable Debug Logging to See Actual Errors

If restore partially works but site is broken, enable debug to see errors.

Enable debug mode

  1. Open wp-config.php
  2. Add before "That's all, stop editing!": 
    define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
  3. Save and upload

Load your site and check debug log

  1. Visit yoursite.com (this triggers errors)
  2. Go to wp-content/debug.log
  3. Download it via FTP
  4. Open in text editor
  5. Look for error messages that explain what's broken

Common debug errors after restore

Error Cause Fix
"Error establishing database connection" Database credentials wrong Check wp-config.php database name, user, password
"Table doesn't exist" Database import didn't complete Verify all tables in phpMyAdmin
"Plugin file missing" Plugin files didn't restore Re-upload plugin files via FTP
"Theme not found" Theme files incomplete Re-upload theme folder via FTP
"Undefined function" Plugin not loading Verify plugin files in wp-content/plugins

Real-World Backup Restore Failure

Scenario: An e-commerce site got hacked. The owner had a backup from UpdraftPlus. They tried to restore via the WordPress admin. Restore got to 45% and timed out. Then they tried again—same result.

What they tried:

  1. Restore via UpdraftPlus: Times out at 45%
  2. Restore via phpMyAdmin: Database too large (1.2GB)
  3. Contacted hosting: They said "use command line"
  4. Didn't know command line, gave up
  5. Site was hacked for a week

What they should have done:

  1. Connected via SSH
  2. Increased PHP memory limit to 1024M
  3. Increased max_execution_time to 600 seconds
  4. Ran database restore via SSH: mysql -u user -p db < backup.sql
  5. Waited 20 minutes for import to complete
  6. Restored files via FTP
  7. Ran WP repair tool
  8. Site recovered in 4 hours

The lesson: Large backups need SSH and increased limits. Web interface tools fail with large data.

Backup Restoration Troubleshooting Checklist

Backup won't restore?

  • ✓ Verify backup file is valid and complete (try extracting locally)
  • ✓ Try different restoration method (plugin restore, SSH, hosting restore)
  • ✓ Increase PHP memory limit to 512M+
  • ✓ Increase max_execution_time to 600+ seconds
  • ✓ Disable all plugins before restoring
  • ✓ Check database character set matches (utf8 vs utf8mb4)
  • ✓ Verify table prefix matches (wp_ vs custom prefix)
  • ✓ Check file permissions after extraction (755 for folders, 644 for files)
  • ✓ Run WordPress repair tool via wp-admin/maint/repair.php
  • ✓ Fix URLs with Search and Replace if needed
  • ✓ Enable debug logging to see actual errors
  • ✓ Try importing via SSH command line for large backups
  • ✓ Contact hosting if still failing

Prevention: Backups That Actually Restore

1. Test restore regularly

Create a test site and restore your latest backup to it every month. Don't wait until you need it to find out it's broken.

2. Keep multiple backup copies

Don't rely on one backup. Keep 3-4 recent backups. If one is corrupted, you have others.

3. Store backups off-site

Don't keep backups only on your hosting server. Download them to your computer and cloud storage (Google Drive, Dropbox, etc.).

4. Use reliable backup plugins

Established plugins (UpdraftPlus, BackWPup, Duplicator) handle large sites reliably. Cheap/free plugins often have issues.

5. Document your restore process

Write down exactly how to restore (which plugin, which settings, which method). When disaster strikes, you won't remember.

6. Keep SSH/FTP credentials accessible

If you need to restore via SSH and don't have credentials, you're stuck. Store them securely (password manager, not notebook).

When to Contact Hosting Support

Contact them if:

  • You can't access FTP or SSH to do manual restore
  • Database import fails even via SSH
  • PHP limits won't increase
  • You get "permission denied" errors during restore
  • Automatic hosting backups are available and you want them restored
  • You've tried all these steps and still can't restore

What to tell them:

"My WordPress backup won't restore. I've tried phpMyAdmin (times out), my backup plugin (fails), and SSH (won't connect). Can you help me restore from backup or provide your automatic backups?"

Most hosting can restore within 1-2 hours.

The Real Talk

Backup failures are terrifying because they threaten your last resort. When the site is broken and the backup won't restore, you feel completely helpless.

But here's what I've learned after restoring hundreds of backups: The backup is almost never the problem. The restoration process is almost always the problem.

Backups fail to restore because:

  • Wrong tool for the job (phpMyAdmin can't handle size limits)
  • Server limits too low (PHP memory, execution time)
  • Configuration mismatch (table prefix, charset)
  • Plugins interfering (security plugin blocking writes)
  • Wrong permissions (files extracted with wrong perms)

These are all fixable. Work through them systematically.

And then, after you successfully restore, immediately set up automatic testing. Restore your backup monthly to a staging site. Know exactly what you'll do when disaster strikes.

A backup you haven't tested is just an expensive feeling of security.

A backup you've tested and restored is actual security.

Make your backups actual.