How to restore a WordPress site from backup

A plugin update went through, and now the site shows “There has been a critical error on this website.” Your host’s panel has a backup from last night, and the Restore button is right there. That button can get you back online in minutes. It can also delete this morning’s orders and bring back a version of the site that breaks in a new way.

Restoring is not an undo. It is a deliberate overwrite, and it works when three things are true. The backup is complete. The route you use still works with the site down. You check the result afterwards. This guide covers all three, using host tools, backup plugins and a manual restore.

Should you restore at all, or fix what broke?

If one change broke the site, undo that change first. When an update causes a fatal error, WordPress usually sends a recovery-mode email that names the plugin. If wp-admin is down, connect over SFTP and rename the plugin’s folder, for example plugin-name to plugin-name-off. WordPress deactivates a plugin when it can’t find its files. Our guide to fixing a WordPress fatal error covers this step by step.

This matters because a full restore replaces everything after the restore point: posts, comments, form entries, users, settings and orders. If someone just overwrote a paragraph, use that post’s revision history. Save the restore for damage that is spread across the site, or for when you can’t find the cause.

What a usable backup has to contain

A working restore needs files and a database taken at the same moment. WordPress’s Advanced Administration Handbook on backups treats them as two separate parts:

• Files: WordPress core, themes, plugins, uploads, wp-config.php and .htaccess.
• Database: posts, pages, users, settings, menus, orders and plugin data, usually saved as a .sql, .sql.gz or .zip file.

If you restore only the files, you get the theme back but no content. If you restore only the database, you get pages and text without the theme, plugins or images. That second case comes up a lot in support threads: someone restores a database-only set and wonders why the design is gone. Mixing a database from one day with files from another causes quieter problems, such as missing images or settings pointing at plugins that aren’t there.

Before you rely on a backup, open the archive and look inside. Check that a database file is there and isn’t 0 KB, and that wp-content includes plugins and themes, not only uploads. A file named “full-backup” proves nothing. Our explainer on what a backup plugin leaves out covers the common gaps.

What to do before you press Restore

1. Back up the broken site. Copy the current files and export the current database, and keep them apart from the backup you plan to restore. If the restore goes wrong, this is how you get back to where you started. It may also hold the only copy of today’s orders or uploads.
2. Check what the host’s snapshot includes. Host tools vary. Kinsta’s documentation says its snapshots include files, the database, redirects, Nginx configuration and MyKinsta settings. It also says restoring an earlier backup can remove domains you added later. Read your host’s page before you confirm.
3. Export anything newer than the restore point. That means orders, customers, form entries, new users and new posts, plus the media files they use. Plan how you’ll bring each one back, because a CSV export isn’t always ready to import.
4. Treat subscription stores as a separate problem. WooCommerce’s guide to restoring backups with Subscriptions calls the time between the backup and the restore a “gap period.” Renewals already processed in that window can come back as Pending, and if they run again, customers get charged twice. WooCommerce describes the cleanup as developer-level work.
5. Keep a copy off the server. Download the backup to your computer or to external storage. A backup kept on the same server is gone if the server or account is lost.
6. Stop new changes. Turn on maintenance mode, tell editors to stop working, and pause checkout. Orders placed during a database restore create one more thing to sort out afterwards.

How to restore with a host tool or backup plugin

On most sites, the host panel is the quickest route. Open the backup list, check that you’re on the right site (agency accounts often list staging and production with similar names), pick the restore point and choose the scope. Pick files and database together unless you’re sure the current files match the older database. A plugin update can change database tables as well as files. Then let the restore finish without making other changes.

Backup plugins work the same way while wp-admin is up. If the dashboard is down, you can’t reach a restore screen inside it. The usual workaround is to install a fresh copy of WordPress, install the same backup plugin, and point it at your remote storage or upload the archives. For UpdraftPlus, put the archive files in wp-content/updraft, then click Rescan local folder so the plugin finds them.

If you can, restore into a fresh install or a staging copy rather than over the broken site. Restoring over an existing install can leave stray files and data behind. A staging copy also lets you test before you send live traffic to it.

How to restore manually with SFTP and phpMyAdmin

A manual restore needs file access (SFTP or the host’s file manager) and database access (phpMyAdmin, or SSH for the command line). Follow the handbook’s order: files first, then the database.

1. Restore the files. Move the current web root aside, then upload or extract the backup in its place. Copying clean files over a compromised site leaves the attacker’s extra files where they are. After extracting, check you haven’t ended up with an extra nested folder such as public_html/public_html.
2. Import the database. An empty database gives the most predictable result. In phpMyAdmin, select the site’s database in the left-hand panel before you open Import. Large files often time out in the browser, so import them from the command line instead.
3. Match the configuration. In wp-config.php, check DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. Then check that $table_prefix matches the restored table names. If the tables are named wp7x_posts and the config says wp_, WordPress acts as if nothing is installed.

The command-line versions, over SSH:

mysql -u dbuser -p dbname < backup.sql
# or, with WP-CLI
wp db import backup.sql

Why the restore failed, and what the log says

Read the restore log before you try again. Running the same restore over and over seldom changes the result. UpdraftPlus’s documentation on restorations that don’t complete matches the common errors to their causes:

Message in the log	Cause	What to do
PCLZIP_ERR_BAD_FORMAT (-10)	Corrupt or incomplete archive	Download it again straight from storage, check it unzips, upload it and rescan. When you delete the bad local copy, leave the option to also delete it from remote storage unticked.
“Allowed memory size … exhausted”	PHP memory limit	Raise WP_MEMORY_LIMIT. If it already equals the server’s limit, ask the host.
“Disk quota exceeded”	No free space	Delete old backups or files, then retry.
“Could not move the files into place”	File permissions	Ask the host to fix ownership. Don’t set folders to 777.

On large sites, restore one part at a time: database, then plugins, themes and uploads separately. Shared hosts often run out of resources on a single upload folder over 1 GB. If the plugin offers to continue an interrupted restore, use that option, then check the result. A half-finished restore can leave parts of the site from different dates.

Old backups bring their own problem. WordPress’s upgrading handbook warns that rolling back can fail when an update changed the database structure. A theme from 2018 on today’s PHP can throw fatal errors even after a clean restore. To get it running, temporarily match the PHP version, or rename the incompatible plugin or theme folder.

The restore finished but the site still looks wrong

“Restore complete” means the tool finished. It doesn’t mean the site works. Check these in order:

• Empty site or install screen: table prefix or database name mismatch in wp-config.php.
• Old pages showing: clear the page cache, any server cache (such as LiteSpeed) and the CDN.
• 404s on every page except the home page: go to Settings > Permalinks and click Save Changes without changing anything.
• Broken images: wp-content/uploads didn’t transfer, or the server can’t read it.
• Wrong content, or another site’s content: you restored the wrong set, or mixed files and a database from different backups.

If you restored to a different domain, don’t run a find-and-replace on the SQL file. WordPress’s migration handbook warns that a plain replace breaks serialized data, the format themes and widgets use to store settings. Use a tool that understands it, and do a dry run first:

wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run

How to check the restored site before reopening

Run the structural checks first: wp db check for table errors and wp core verify-checksums for changed core files. Then test what the business depends on:

• Log in to wp-admin as an existing user.
• Load the home page and your main landing pages. Check the text, images and menus.
• Submit a form and confirm the email arrives, not just the thank-you message.
• Open a recent upload in the Media Library.
• On a store, place a test order with sandbox payment details. Check recent orders, subscriptions and the scheduled actions under Tools > Scheduled Actions.

If the restore followed a hack, the backup may already be infected, and the hole the attacker used is still open. Confirm the backup is from before the compromise. Then go through the admin users, plugins and scheduled tasks, update everything and change passwords. Our WordPress security issues guide covers the containment steps.

When to stop and get help

Stop when you’ve tried twice with the same error, when the log says the database is invalid, when subscription renewals fall in the gap period, or when you can’t tell whether the backup is clean. At that point, more attempts add risk without adding information. Ask your host for a newer copy, or ask the previous developer, before anyone quotes for a rebuild. Pages that look “missing” are sometimes sitting in a backup someone else holds.

If you’d rather hand over the diagnosis, SiteSelf works on the live site through chat, using hosting access for file and database work. Before it changes anything, it says what it’s about to change and whether that can be undone, and afterwards it reports what it checked. Here is how SiteSelf handles broken sites.