Guide Backups & Recovery

How to restore a database from a backup

The database half of a restore has its own tools and its own common errors — here is how to do it properly.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

Restoring the database half of a backup is a different job from restoring files, with its own tools and its own way of going wrong. This guide covers it on its own — if you need the files half too, restoring a website from a backup covers both together.

Before you start

Confirm three things: which .sql file you are restoring, which database it needs to go into, and whether that database already has data in it that a restore would need to overwrite or clear first. If you are restoring into a fresh, empty database created specifically for this, the process below is simpler and the common errors mostly do not apply.

Method 1: phpMyAdmin

Open phpMyAdmin, select the target database from the list on the left, and choose the Import tab. Choose your .sql file, leave the format as SQL, and submit.

phpMyAdmin has an upload size limit

Most installations cap how large a file you can upload directly, which a full database export can exceed. If your import fails immediately with no useful error, this is usually why. A compressed file — phpMyAdmin can generally import a .sql.gz directly — often fits under the limit even when the uncompressed version does not. For anything that still does not fit, use the command line instead.

Method 2: the command line

Over SSH, importing a plain SQL file is one command:

mysql -u username -p database_name < backup.sql

If your backup is compressed, decompress it into the import in one step rather than creating an extra uncompressed copy on disk first:

gunzip < backup.sql.gz | mysql -u username -p database_name

This method has no practical file size limit in the way phpMyAdmin does, which makes it the reliable option once a database gets into the hundreds of megabytes or larger.

Restoring into a brand new database

If you are restoring somewhere other than the original site — a new hosting account, a staging copy, a fresh test environment — the cleanest approach is to create an empty database and a database user specifically for this restore, rather than reusing one that already holds other data. That sidesteps most of the "table already exists" and permissions problems below before they happen, because there is nothing already in the database to conflict with. Creating a MySQL database and user covers that step if you have not done it before.

Errors you will actually run into

Error	What it means	Fix
`Table already exists`	The target database already has tables with the same names	Restore into an empty database, or use a dump that includes `DROP TABLE IF EXISTS` statements before each table
`Unknown collation`	The dump was created on a MySQL version newer than the one you are restoring into	Edit the collation reference near the top of the file to one your server supports, or restore on a matching version if possible
`MySQL server has gone away`	A single statement in the import is larger than the server allows	This is controlled by `max_allowed_packet`; on a managed hosting account this generally needs support rather than a setting you can change yourself
`Access denied for user`	Wrong username, password, or a user without permission on this specific database	Confirm the credentials and that the database user has been granted access to the target database

If the database name, user, or host has changed

Restoring into a different environment than the one the backup came from — a new hosting account, a different database name — restores the data correctly but does nothing to update the application that reads it. Most platforms hold their database connection details in a single configuration file; that file needs to be updated to match wherever the database actually ended up, or the site will still show a database connection error even though the import itself succeeded. This is especially relevant during a migration rather than a same-account restore, and is a common last step people forget.

Verify before you move on

Open a few tables in phpMyAdmin's Browse view and confirm the data looks like what you expected — recent rows present, row counts roughly matching what you know the site should contain. Then load the actual site and check anything that reads from the database directly: a login, a search, a listing page. A database that imported without errors can still be the wrong export, or an older one than you meant to use, and the only way to catch that is to look at what is actually in it.

Once you are confident the database is right, it is worth confirming the whole site behaves as expected using the same approach as any other restore — see testing that a backup works for the fuller checklist.