Something went wrong with your WordPress site and you need to roll back to a working backup. Maybe a plugin update broke everything. Maybe malware got in. Maybe you migrated to a new server and need to bring your content over. Whatever the reason, you have a tarball of your files and a MySQL dump of your database, and you need to put them back together.
This guide covers the full manual restoration process via the command line. If you followed our guide on how to back up WordPress manually, you already have the two files you need: a
.tar.gz
archive of your WordPress files and a
.sql
(or
.sql.gz
) dump of your database. If your backup came from your hosting provider or another tool, the process is the same as long as you have those two components.
Before you start#
Verify your backup files
Confirm that both backup files exist and aren’t corrupted before you start tearing apart your live site.
Check the archive can be read:
tar -tzf backup.tar.gz | head -20
This lists the first 20 files in the archive. If you see a normal directory listing (wp-config.php, wp-content/, wp-includes/), the archive is intact. If you get an error about a corrupted or truncated file, the archive is damaged and you’ll need a different backup.
Check the SQL dump:
# For uncompressed .sql files
tail -5 backup.sql
# For compressed .sql.gz files
zcat backup.sql.gz | tail -5
The last line of a valid mysqldump should read something like
-- Dump completed on 2026-02-27
. If it’s cut off mid-statement, the dump is incomplete.
Note your current state
Before overwriting anything, record what you currently have in case you need to undo the restore:
# Check your current database name and credentials
grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" /path/to/wordpress/wp-config.php
Write these down. You’ll need them if the restore doesn’t go as planned and you want to revert.
Step 1: Upload your backup files#
If your backup files are on your local machine, upload them to the server using SCP or SFTP.
From your local machine via SCP:
scp backup.tar.gz backup.sql username@your-server-ip:~/
scp backup.sql username@your-server-ip:~/
This places both files in your home directory on the server. If your host uses a non-standard SSH port, add
-P
followed by the port number.
Via SFTP using FileZilla, WinSCP, or Cyberduck: connect with your SSH credentials and drag the files to your home directory.
If the backup files are already on the server (from your hosting provider’s backup system or a previous download), skip this step.
Step 2: Prepare a recovery directory#
Don’t extract files directly into your live WordPress directory. Work in a separate location so your live site stays up until the restored version is ready.
mkdir ~/recovery
cp ~/backup.tar.gz ~/recovery/
cd ~/recovery
Step 3: Extract the WordPress files#
Unpack the tarball:
tar -xzvf backup.tar.gz
The
-v
flag shows every file as it’s extracted. For large archives this produces a lot of output; use
-xzf
(without
v
) for a quieter extraction.
After extraction, verify the directory structure looks right:
ls -la ~/recovery/
You should see standard WordPress files and directories:
wp-config.php
,
wp-content/
,
wp-includes/
,
wp-admin/
,
index.php
, and so on. If the archive contained a parent directory (like
public_html/
), you’ll see that folder instead and your WordPress files will be one level deeper.
Set file permissions
Backups don’t always preserve the correct permissions, especially if the archive was created on a different server or by a different user. Set standard WordPress permissions:
# Set directories to 755 (owner: read/write/execute, group+others: read/execute)
find ~/recovery -type d -exec chmod 755 {} +
# Set files to 644 (owner: read/write, group+others: read)
find ~/recovery -type f -exec chmod 644 {} +
# wp-config.php should be more restrictive
chmod 640 ~/recovery/wp-config.php
Using
+
instead of
\;
at the end of the
find
command batches the chmod operations, which is significantly faster on directories with thousands of files.
Step 4: Restore the database#
Decompress the SQL dump if needed
If your database backup is compressed:
gunzip backup.sql.gz
Create a fresh database (if needed)
If you’re restoring to a new server or want a clean database, create one. If you’re restoring over your existing database, skip to the import step.
mysql -u root -p -e "CREATE DATABASE wordpress_db;"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost' IDENTIFIED BY 'your_password'; FLUSH PRIVILEGES;"
Replace the database name, username, and password with your values. If you don’t have root MySQL access (common on shared hosting), create the database through your hosting provider’s control panel.
Import the dump
mysql -u wp_user -p wordpress_db < backup.sql
Enter the password when prompted. Depending on the size of your database, this can take anywhere from a few seconds to several minutes. There’s no progress indicator; just wait for the prompt to return.
Verify the import worked:
mysql -u wp_user -p wordpress_db -e "SHOW TABLES;"
You should see your WordPress tables listed (typically prefixed with
wp_
unless you changed the prefix). A standard WordPress installation has around 12 core tables, plus additional tables from plugins.
Step 5: Update wp-config.php#
If your database credentials have changed (new server, new database name, new user), update
wp-config.php
in your recovery directory before moving it to production:
nano ~/recovery/wp-config.php
Find and update these lines:
define( 'DB_NAME', 'wordpress_db' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'your_new_password' );
define( 'DB_HOST', 'localhost' );
If you’re restoring to the same server with the same database, and the credentials haven’t changed, you can skip this step.
Update the site URL (for migrations)
If the domain name has changed (restoring to a different domain or a staging environment), update the URLs in the database:
mysql -u wp_user -p wordpress_db -e "UPDATE wp_options SET option_value='https://newdomain.com' WHERE option_name='siteurl';"
mysql -u wp_user -p wordpress_db -e "UPDATE wp_options SET option_value='https://newdomain.com' WHERE option_name='home';"
Without this, WordPress will redirect to the old domain and you won’t be able to access the site.
Step 6: Swap into production#
Now the critical moment: replacing your live files with the restored ones. This causes a brief period of downtime, so do it during low-traffic hours if possible.
Rename the current directory as a fallback
mv /path/to/public_html /path/to/public_html_old
This preserves your current (broken) site in case you need to revert. Don’t delete it yet.
Move the restored files into place
mv ~/recovery /path/to/public_html
Replace
/path/to/public_html
with your actual web root. If your archive extracted into a subdirectory (like
public_html/
inside the recovery folder), adjust the path accordingly:
mv ~/recovery/public_html /path/to/public_html
Set ownership
If your web server runs as a specific user (common on shared hosting), set the correct ownership:
chown -R username:username /path/to/public_html
Replace
username
with your actual server account username. On some hosts, the web server user is
www-data
or
nginx
and you’ll need the files owned or readable by that user. Check your hosting provider’s documentation or look at what the old directory used:
ls -la /path/to/public_html_old/
Match the ownership pattern you see there.
Step 7: Verify the restore#
Load your site in a browser. Check the following:
- Homepage loads correctly with the expected content, images, and layout
- Internal pages and blog posts display properly
- WordPress admin panel is accessible at
/wp-admin/and you can log in - Media uploads (images in posts and pages) display correctly
- Plugin functionality works (forms, sliders, WooCommerce products, etc.)
- Permalinks work. If you get 404 errors on pages that aren’t the homepage, go to Settings > Permalinks in the admin panel and click “Save Changes” without changing anything. This regenerates the rewrite rules.
Flush any caching
If your server uses nginx caching, object caching (Redis, Memcached), or a caching plugin, flush everything after the restore. Cached pages from before the restore can show outdated or broken content.
Clear your browser cache too, or test in an incognito window, to make sure you’re seeing the actual restored site and not a locally cached version.
Step 8: Clean up#
Once you’ve confirmed everything works:
Remove the old site files
rm -rf /path/to/public_html_old
Only do this after you’re fully confident the restore is successful. Once deleted, you can’t get these files back.
Remove the backup files from the server
rm ~/backup.tar.gz ~/backup.sql
Don’t leave backup archives sitting on the server. The SQL dump contains your database credentials and all your content. The tarball contains
wp-config.php
with your database password. Both are security risks if they’re in a web-accessible location.
Troubleshooting common restore issues#
“Error establishing a database connection” after restore: The database credentials in
wp-config.php
don’t match the actual database. Double-check
DB_NAME
,
DB_USER
,
DB_PASSWORD
, and
DB_HOST
.
Site redirects to the old domain: The
siteurl
and
home
values in
wp_options
still point to the old address. Update them with the MySQL commands in step 5.
Broken images and media: Your uploads directory (
wp-content/uploads/
) might be missing or the file paths in the database might reference a different directory structure. Check that the uploads folder exists and contains your media files.
404 errors on all pages except the homepage: Permalink rewrite rules need to be regenerated. Go to Settings > Permalinks and click “Save Changes.” If you can’t access the admin panel, create or update your
.htaccess
file (Apache) or check your Nginx configuration for the proper WordPress rewrite rules.
Permission denied errors: File ownership or permissions are wrong. Revisit step 3 for permissions and step 6 for ownership. The web server process needs to be able to read all WordPress files and write to
wp-content/uploads/
.
White screen after restore: PHP version mismatch. If the backup was created on a server running PHP 7.4 and you’re restoring to PHP 8.x, some plugins or themes may be incompatible. Check the PHP error log for specifics. See our guide on fixing the WordPress White Screen of Death for detailed troubleshooting.
For more WordPress restoration methods, see the WordPress restoration documentation.
Try Hostney web hosting free for 14 days. Every plan includes automated daily backups with one-click restore, plus full SSH access when you need manual control.