Restoring a Site Backup: A Practical, Error-Free Guide

The site won't come up, or it's showing a white screen, or everything got messed up after an incomplete update. The first thing most admins do is dump yesterday's entire backup onto today's site. In half of cases, this makes things worse. Restoring a backup is a surgical operation, not a big copy-paste. Before any command, you need to know exactly what's broken and what's healthy.

Diagnose first, then restore

Before you touch the backup files, check three things. First, look at the PHP error log; if the error comes from a specific plugin or file, there's no need to restore the entire site. Second, see whether the database responds or not. Third, check whether the problem is with DNS or the server, or with the code itself. If the domain points to the wrong IP, no backup will fix the problem. For this step, you can use the DNS and network lookup and make sure the problem is with resolution, not with content.

A simple test: create a test.php file with the content <?php echo "ok"; and open it in your browser. If you see "ok", the web server and PHP are healthy and the problem is in the application. If you get a 500, the problem is on the server side or in the config. If it's a white screen, you probably have a PHP error that isn't being displayed.

Full restore versus partial restore

A full restore means returning all files and the entire database to a point in time. This is only logical in three cases: the site was hacked, the database is corrupted, or you're migrating to a new server. In other cases, a partial restore is both faster and less risky.

Note in the table above that the time column depends on the site's size. A 500 MB site with a 200 MB database on a typical shared host can take more than an hour for a full restore, because both uploading and extracting the files take time.

Database restoration: commands and practical tips

Suppose you have the database backup file: backup.sql created with mysqldump. To restore it from the SSH command line:

mysql -u dbuser -p dbname < backup.sql

If the file is gzip-compressed, decompress it first or pipe it directly to mysql:

gunzip < backup.sql.gz | mysql -u dbuser -p dbname

A point many people don't know: if you took the backup with mysqldump --single-transaction, the output file doesn't include DROP TABLE IF EXISTS unless you also added --add-drop-table. That means when you import the file onto the current database, existing tables remain untouched and only records get added. The result is that after restoration, your site has two copies of every post. If you want the database to be fully replaced, empty it first:

mysql -u dbuser -p -e "DROP DATABASE dbname; CREATE DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Then import the file. Here's where people make a mistake: many import the backup without emptying the database, and after seeing duplicate records they think the backup is corrupt. In reality, the backup was fine; the destination database wasn't ready.

Restoring just one table

If only one table is corrupted, you don't need to restore the entire database. You can extract just the section related to that table from the SQL file. This can be done with sed or awk, but it's simpler to select and import the table with a tool like phpMyAdmin. If the backup file is large (over 50 MB), phpMyAdmin usually times out. In that case, use the command line or split the file into chunks.

Restoring files: what to keep

Before replacing the public_html folder with the backup, set these aside:

• The current wp-config.php, because the database credentials or security keys may have changed.
• The uploads folder if you have newer files than the backup date.
• The .htaccess file if it contains redirects or specific settings.
• The wp-content/plugins folder if you installed a plugin after the backup date.

After replacing, fix the file permissions. Wrong permissions are one of the common causes of a 403 error after restoration:

find /home/user/public_html -type d -exec chmod 755 {} \;
find /home/user/public_html -type f -exec chmod 644 {} \;

If the site is on shared hosting, the number of files also matters. Restoring an old backup that has thousands of extra files can bring you close to the inode limit. Before restoring, count the current and backup file counts. The guide on inode limits in hosting explains what consumes this number and how to count it.

Before restoring, do these three things

1. Take a backup of the current state, even if it's broken. You may later need a specific file from it.
2. Put the site in maintenance mode so users don't encounter errors mid-restoration.
3. Make sure you have enough disk space. Extracting a 2 GB backup on a host with 1 GB of free space will stop midway.

Take the third point seriously. A No space left on device error mid-extraction leaves the site in a half-restored state, which is the worst possible scenario. If you don't have enough space, first delete unnecessary files like logs and caches.

Choosing between panel restore and command line

If the backup is under 100 MB and the database is small, use the hosting panel. It's faster and there's no risk of command mistakes. If the backup is larger, or you need to restore just one table, or the site is on a dedicated server, the command line is the better choice. On the command line you have full control and can stop midway or restore only part of it.

A practical limitation that's rarely mentioned: on shared hosting, the restoration process itself consumes resources. If the restoration takes long, you may hit the Entry Process limit and the process gets killed midway. You can see this precisely in the Entry Process explanation. In such a case, do the restoration during low-traffic hours or temporarily take the site offline.

If your site is on Linux hosting and you have a large backup, it's better to put the file directly on the server with wget or scp, not through the browser. Browser uploads for files over 100 MB usually get interrupted.

What to check after restoration

Once the restoration is done, don't just open the site and say "well, it's fixed." Check these:

• Do the homepage, a post, and a static page open correctly?
• Does the contact form work? (Some plugins store their settings in the database and they may be outdated.)
• Do internal links point to existing files?
• Is SSL still active? If the backup is old, the HTTPS redirect may be missing from .htaccess.
• Has the cache been cleared? An old cache can show the previous version of pages and make you think the restoration didn't work.

If you use WordPress, after restoring the database, check the site URL in the wp_options table. If the backup was taken from another domain, the URLs will be wrong and the site will redirect to the old domain. You can see this with a simple query:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');

If the value is wrong, fix it with UPDATE. Here's where people make a mistake: many think the problem is with DNS and start changing nameservers, while the problem is just one record in the database. If you're not sure whether the problem is DNS or the database, check DNS first. The guide on connecting a domain to hosting explains the difference between nameservers and A records and helps you tell the two apart.

Frequently asked questions

Can I restore only the database and leave the files alone?

Yes, and in many cases this is the right approach. If the problem is with the content or database settings and the site files are healthy, restore only the database. Just remember that if you've updated a plugin and its table structure has changed, restoring an old database can cause incompatibility.

Why does the site still show errors after restoring the backup?

Three common reasons: the browser or server cache hasn't been cleared, file permissions changed after extraction, or the PHP version isn't compatible with the restored code. If the backup was taken from a server with PHP 7.4 and the current server has PHP 8.2, the old code may throw errors. To check settings, see the php.ini directives reference.

What command should I use to take a backup that's easy to restore?

For a MySQL database, the command mysqldump -u user -p --single-transaction --routines --triggers dbname > backup.sql covers the essential options. For files, tar -czf backup.tar.gz public_html is enough. If you want the backup to be partially restorable, keep folders separate instead of one big tar file.

How long does a full restore take?

It depends on the backup size, disk speed, and hosting type. On a shared host with a regular disk, each gigabyte of files takes about 5 to 15 minutes. On a server with NVMe, this drops to less than 2 minutes per gigabyte. If time matters, do the restoration during low-traffic hours and check disk space beforehand.

Before any restoration, take a backup of the current state. This is the only thing that will save you if you make a mistake.