Guide WordPress

How to restore a WordPress backup

Restoring files and database together, whichever way you took the backup, and the checks to run once the site is back.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

Restoring a WordPress backup is the same two-part job as taking one: files back in the web root, database back in MySQL, both matching each other. Which method you use depends on how the backup was taken in the first place.

Before you restore anything

Back up the current state first, even if it is broken

A restore overwrites what is there now. If the current site holds anything you have not already got safely backed up elsewhere — recent orders, comments, a post published this morning — take a backup of it before you restore over the top, even if it is the broken version. You can always discard it afterwards, but you cannot get it back once it is overwritten.

Method 1: restoring from your control panel

If the backup was taken through your control panel's own backup tool, this is the simplest route, because it restores files and database together in one operation without you having to handle either separately.

Open the backups section of your control panel
You will see a list of available snapshots, usually with a date and time for each.
Choose the snapshot to restore
Pick the most recent one taken before the problem started, not necessarily the very latest — if the site has been broken for a day, the newest backup may already contain the problem.
Choose what to restore
Most control panels let you restore files only, database only, or both. For a full recovery, restore both.
Confirm and wait
Restoring can take anywhere from a couple of minutes to considerably longer on a large site. Let it finish before checking the site.

Method 2: restoring with a backup plugin

If a plugin took the backup and pushed it to cloud storage, that same plugin is usually how you restore it — from inside wp-admin if the site still loads, or via its own separate restore tool if it does not.

If wp-admin still loads: open the plugin's page, find the backup you want, and use its restore option. Follow its prompts for files, database, or both.
If wp-admin does not load: most backup plugins ship a small standalone restore script you upload to the server separately from WordPress itself, which then unpacks the backup without needing WordPress to be working first. Check that plugin's own documentation for the exact file name and process, since this varies between plugins.

Method 3: restoring by hand

Needed when you only have a raw files archive and a .sql database export — the situation after a manual backup, or when moving a backup between two different systems entirely.

Restore the files

Upload the files over FTP or through the file manager into the web root, replacing what is currently there. If the backup is a single zip archive, it is usually quicker to upload the zip itself and extract it on the server through the file manager than to upload thousands of individual files over FTP.

Restore the database

In phpMyAdmin, select the target database, choose Import, and select your .sql file. See importing a database with phpMyAdmin for the full walkthrough, including what to do if the file is too large for the web upload limit.

Import into the right database

Importing overwrites tables that already exist without asking twice. Confirm you have the correct database selected before you click Import, especially on an account that hosts more than one site.

Match wp-config.php to the restored database

If you restored into a database with a different name, username or host than the original — common when restoring to a new hosting account — update the corresponding values in wp-config.php to match. A backup that restores files and a database that no longer agree with each other about connection details will not load at all.

After restoring: check the site is actually right

A restore that runs without an error is not automatically a restore that worked. Check:

The homepage loads and shows the content you expected from that point in time.
You can log into wp-admin with an account from that backup.
Images and uploads appear — a files restore that missed wp-content/uploads shows broken image icons everywhere.
The site URL is correct. A backup restored to a different domain or a different path — moving from a staging subdomain to the live domain, for instance — often needs its site URL corrected. See changing a WordPress site URL if links or the admin area point at the wrong address.
Permalinks work. If individual posts return a 404 error after a restore, go to Settings, then Permalinks, and save once without changing anything — this regenerates the rewrite rules the server needs.

If the restore itself fails

Database import times out or fails partway. The file is likely too large for phpMyAdmin's upload limit — use a command-line import instead, or split the file, as covered in importing a database too large for phpMyAdmin.
The site shows a database connection error afterwards. Check the four values in wp-config.php against the database that was actually restored into — this is the single most common cause.
Some content from just before the backup is missing. That is expected — a backup only contains what existed at the moment it was taken. Anything created after cannot be recovered from it.

If you took a backup you have never actually restored before, this is also the moment to learn whether it works at all — see testing that a backup works so the next restore is not the first time you find out.