How to Restore a WordPress Database From a Backup

To restore a WordPress database, you need an SQL dump (usually a .sql or .sql.gz export) and access to the server. Export what is there now first, then import the backup with your host’s restore tool, phpMyAdmin or WP-CLI, check that wp-config.php points at the right place, and test the site with caches cleared. The import replaces posts, pages, settings, users and orders with the state they were in when the backup was made, so anything added since then is lost unless you save it separately. If no dump exists at all, the content cannot be imported back, but the public pages can often be rebuilt from other sources.

Is a database restore the right fix?

The database stores the text and settings of a WordPress site: posts, pages, comments, users, menus, theme and plugin options, page builder layouts and WooCommerce orders. Theme code, plugins and uploaded media live in files. So a database restore is the right tool when content or settings changed or vanished while the theme still loads, and the wrong tool when only images or code are missing.

If images are missing but posts are fine, you need the uploads folder instead. If posts vanished but the theme still loads, an SQL import is the place to start. If both are gone, see our guide for when a WordPress database is lost but files remain and the related deleted WordPress site walkthrough.

Before you restore: protect what is there now

1. Export the current database. Even broken or hacked tables are evidence and may contain recent orders or comments you want later. In phpMyAdmin, select it and use Export; with WP-CLI, run wp db export before-restore.sql.
2. Find the name and prefix. Open wp-config.php and note DB_NAME, DB_USER and $table_prefix. You will import into this one, and the dump must use the same table prefix (often wp_).
3. Check the backup file. Open it in a text editor (or look inside the archive) and confirm it contains CREATE TABLE and INSERT statements for tables such as wp_posts and wp_options, and that the date is the one you want.
4. Put the site in maintenance mode or restore to staging first. A restore to a staging copy lets you check the result before visitors see it.

How to restore a WordPress database: three methods

Method 1: your hosting control panel

Most hosts keep their own daily backups and let you roll back just the MySQL data. On cPanel hosts this is often under Backup or a tool such as JetBackup; SiteGround has Restore Database in Site Tools (see how to restore a SiteGround website); Hostinger has it under Backups in hPanel. Choose the date before the problem, select the MySQL part only, and confirm. This is the easiest route because the host handles the import and the credentials do not change.

Method 2: phpMyAdmin import

This is the method described in the WordPress documentation on restoring your database from backup:

1. Open phpMyAdmin from your hosting panel and click the name listed in wp-config.php.
2. If you are replacing everything, select all tables (Check all) and choose Drop. Only do this after the export in the previous section.
3. Open the Import tab, choose your .sql or .sql.gz file, keep the format as SQL and click Import (or Go).
4. Wait for the success message, then load the site and the dashboard.

Large backups can exceed phpMyAdmin’s upload limit. If the import stops with a size or timeout error, split the file, ask your host to import it, or use WP-CLI.

Method 3: WP-CLI

If you have SSH access, WP-CLI is the most reliable way to import large dumps. From the WordPress folder:

1. wp db export before-restore.sql to keep a copy of the current state.
2. wp db reset --yes only if you want empty tables before the import (this deletes every table).
3. wp db import backup.sql to load the backup.
4. wp cache flush and, if you use a caching plugin, purge its cache.

The commands are documented in the WP-CLI db import reference.

After the restore: checks that catch most problems

• Site address: in wp_options, siteurl and home must match the live domain, including https. If the backup came from a staging or old domain, update these values and run a careful search-replace (wp search-replace handles serialized data safely; plain SQL find-and-replace can break it).
• Permalinks: visit Settings > Permalinks and click Save to refresh rewrite rules if inner pages return 404 errors.
• Logins: user accounts and passwords are back to the backup’s state. Anyone added since then must be re-added.
• Shop data: WooCommerce orders and stock levels since the backup date are missing after the rollback. Compare with payment-provider records and the export you made before restoring.
• Credentials: if WordPress cannot connect after you imported into a new or renamed MySQL schema, the name, user or password in wp-config.php are out of date; the guide to fixing a WordPress connection failure walks through each setting.

Restoring only part of a WordPress database

Sometimes you need one deleted page back, not a full rollback. Rolling back everything would wipe out everything else that changed. Safer options:

• Import into a staging site, then copy the missing post across with the WordPress exporter (Tools > Export) and import it on the live site.
• Check the trash and revisions first. Deleted posts sit in the trash for 30 days by default, and revisions can bring back earlier text. Our article on how to recover deleted WordPress posts covers those routes.
• Restore single tables only if you understand how they relate. Posts in wp_posts depend on wp_postmeta and term tables; restoring one without the others can leave broken pages.

Fixing common import errors

Most failed restores come down to a handful of messages. Read the first error line phpMyAdmin or WP-CLI prints, then match it here:

Restoring from a backup plugin archive

Backup plugins package the SQL differently, and the restore route follows from that:

• UpdraftPlus stores the SQL as a separate -db.gz file. On a working WordPress install with the plugin active, upload the set under Existing backups and tick only Database when restoring. You can also unzip the gz and import the SQL manually.
• Duplicator bundles everything into an archive plus an installer.php. The installer creates or overwrites the tables during its steps; extracting the archive by hand gives you a database.sql file you can import yourself.
• BackWPup and similar tools place a .sql file inside the zip archive. Extract it and use phpMyAdmin or WP-CLI.
• Host-made downloads (cPanel full backups) contain a mysql folder with one .sql file per database; import the one whose name matches DB_NAME.

When there is no database backup to restore

Without a dump, the posts and settings cannot be imported back. Ask your host whether their own backups still include it, check backup plugins’ remote storage, and ask any developer who worked on the site for copies. If nothing exists, the public content can still be rebuilt: the Wayback Machine and other archives keep copies of pages visitors could see. They do not contain MySQL data, users, orders, form entries or private content, and they only include pages that were crawled.

Our WordPress restoration service rebuilds posts, pages, menus and images into a fresh, editable WordPress install from those captures and any partial copies you have. Start with the free restoration check to see how much of the site was archived; we explain what is missing before any work starts.

Frequently asked questions

Will an SQL import bring back my images?

No. Images are files in wp-content/uploads. The tables only store references to them. If the files are missing, restore them from a file backup as well.

Can I restore a WordPress database to a different domain?

Yes, but update siteurl and home and run a serialized-safe search-replace for the old domain, otherwise links, images and builder layouts may still point to the old address.

Why do I get errors when importing the .sql file?

Common causes are a file larger than the upload limit, tables that already exist, a different table prefix, or a MySQL version mismatch. Read the error line, drop or rename conflicting tables after exporting them, or import with WP-CLI.

How often should I back up WordPress content?

As often as content changes. A blog updated weekly can live with daily backups; a busy shop needs more frequent copies, kept somewhere other than the hosting account.