Guide Backups & Recovery

How to restore a website from a backup

A restore overwrites the live site with the backup, so do it in the right order — here is what that order is.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

A restore is not additive. It does not merge the backup with what is currently live — it overwrites the current state with the saved one. Anything that changed between the backup date and now, whether that is new orders, new comments, or new files, is not in the backup and will not survive a restore that replaces everything. Understanding that one fact before you start is most of what makes a restore go well.

Back up the current, broken state first

Even a site that is currently broken may contain something the last good backup does not: today's form submissions, a database change nobody has copied yet, a file someone uploaded an hour ago. Take a backup of the site as it stands right now, before you restore over it, so that data is not lost twice.

Work out what you actually have

Before restoring anything, confirm three things: which backup you are restoring from, whether it covers files, the database, or both, and how old it is. A backup that only covers the database will bring content back without the images that go with it; a files-only backup does the opposite. If your only backup is one half, restore that half and rebuild the other separately rather than assuming the backup does more than it does.

Method 1: your hosting control panel

If your backup was taken through the backups section of your control panel, restoring is normally the fastest and least error-prone option, because the tool restores files and databases together and keeps them consistent with each other. Choose the restore point, confirm what it will overwrite, and start the restore. On a large account this can take some time — resist the urge to interrupt it, since a restore stopped halfway can leave the site in a worse state than either the old or new version alone.

Method 2: restoring by hand

Needed when you are restoring from a backup you downloaded yourself, or moving a backup between accounts.

Restore the files

Connect over FTP or SFTP and upload the contents of your backup archive to the web root, overwriting what is there. If your backup is a compressed archive and you have shell access, it is faster to upload the single file and extract it on the server:

tar -xzvf backup.tar.gz -C public_html/

Check file ownership and permissions after extracting — an archive built on a different system can restore files with permissions that stop the web server reading them, which shows up as a blank page or a permissions error rather than the site itself.

Restore the database

In phpMyAdmin, select the target database, choose Import, pick the .sql file, and confirm SQL as the format. Over SSH, one command does the same job:

mysql -u username -p database_name < backup.sql

Restoring into a database that already has tables in it commonly fails with "table already exists" errors, because the dump tries to create tables that are already there. Either restore into a freshly emptied database, or use a dump that includes DROP TABLE IF EXISTS statements, which most export tools add by default. Restoring a database from a backup covers this case in more detail.

Restore to a copy first, when you can

If the current site is not completely down, restoring straight over it means you cannot compare before and after, and any mistake in the restore is now the only version that exists. Where time allows, restore to a staging subdomain or a local copy first, confirm it looks right, and only then repeat the process on the live site. Creating a staging copy covers setting one up.

When the site is genuinely down and every minute matters, that extra step is a luxury you may not have — restore straight to live, then verify immediately afterwards instead of before.

After the restore

Load the site and click through it. Home page, a few inner pages, and anything that touches the database, such as a login form or a search box.
Check the date. If the restore point was from before a recent change, that change is gone and needs redoing, not just noticing.
Clear caches. Both any caching plugin or service the site uses, and your own browser cache, so you are looking at the restored version rather than a cached copy of the old one.
Rotate credentials if the restore followed a compromise. A backup taken before an attacker got in restores clean files, but it does not undo the fact that your passwords may have been seen. Recovering from ransomware covers this case specifically.

If the restore did not fix it

Two situations are common. The backup itself may have been incomplete or corrupted, which is exactly what testing a backup in advance is meant to catch — see testing that a backup works. Or the fault was never in the files or database at all — a DNS change, a broken third-party service, or a server-level setting can look identical to a broken site while being untouched by any restore. If a restore has not resolved the problem, contact support with what you tried and when the backup was taken, so we can look at what else might be going on.