It is late, the site is down, and you have a file called backup-final-2.zip. You know it is the thing that brings everything back. You do not know which part goes where, and the first thing phpMyAdmin asks you is whether to “replace” your database.
Here is how to restore a WordPress website from a backup. The job is not hard. It is unforgiving about order. Get the order right and the rest is copying.
Before you touch anything
Three checks first. Each one has saved more sites than any plugin.
- Do you have both halves? A complete website backup for WordPress is the files (core, themes, plugins, uploads,
wp-config.php,.htaccess) and a database export, usually a.sqlfile or a compressed.sql.gz. WordPress.org’s handbook is plain that you need both to fully restore a typical site (developer.wordpress.org, WordPress Backups). Open the archive and look. - Is the backup from before the problem? If you are restoring because of a hack, a backup taken after the attacker got in will put the attacker straight back.
- Back up the current state, even if it is broken. Restoring a database replaces what is there. If the backup turns out to be bad, the broken site is still better than nothing.
The order that works
WordPress.org’s recommended order is short (WordPress Backups):
back up: database → files. Restore: files → database → fix wp-config.php if the database details changed
Files first, because WordPress needs its code and its wp-config.php in place to talk to the database. Database second, because that is where your content comes back. Then make sure the two still recognise each other.
Step by step: a manual restore
1. Put the files back
Connect by SFTP (or your host’s file manager) and upload the WordPress folder from the backup to the site’s web root, often public_html. If you are restoring over a damaged site, upload into an empty folder rather than on top of the old files, so nothing from the broken version survives by accident.
2. Prepare the database
In your hosting panel, either use the existing WordPress database or create a new empty one with a user that has full rights on it. One detail from the handbook matters here: a phpMyAdmin Quick export should go into a database with no tables in it. A Custom export made with the DROP TABLE option will overwrite existing tables of the same name.
3. Import the database
With phpMyAdmin, per the handbook (developer.wordpress.org, Backing Up Your Database):
- Log in and select the target database.
- Open the Import tab, click Browse, and pick the backup file.
- Make sure the format is SQL.
- Click Go. The current contents of that database are replaced by the backup.
For a large database, the handbook says phpMyAdmin will not cope and recommends the command line. Decompress if needed, then:
mysql -h DB_HOST -u DB_USER -p DB_NAME < site-db.sql4. Point wp-config.php at the database
If you restored into a new database, or your host changed the database user or password, open wp-config.php and update DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. If the table prefix in the backup is not wp_, the $table_prefix line must match it too. An “Error establishing a database connection” after a restore usually points to this file.
5. Moving to a new domain? Handle the URLs
The database stores the site’s address. If you restore to a different domain, WordPress.org’s migration guide warns against a blind find-and-replace across the whole database, because some themes and widgets store values with the length of the URL recorded, and changing that length breaks them. It points to tools that handle this properly, including WP-CLI’s search-replace command, and says never to change the GUID column (developer.wordpress.org, Moving WordPress).
6. Check it like a visitor
Log in, then re-save Settings → Permalinks once (many people do this to refresh the rewrite rules; see the WordPress documentation for the Permalinks screen). Open the homepage, a few posts, an image-heavy page and the contact form. Log out and check again in a private window.
Restoring with cPanel
Many people searching “restore full website backup cPanel” hit the same wall. cPanel’s own documentation says you cannot automatically restore a full backup file from inside cPanel; that function is only available in WHM, the server-level panel, so for a one-click full restore you contact your host (cPanel Docs, Backup).
What you can do yourself, per the same page: restore partial backups, such as the home directory, through cPanel’s Backup tool, or extract the full backup archive on your computer and upload the public_html files manually. The database then goes in through phpMyAdmin as in step 3 above. That is the manual restore again, just with cPanel’s file manager doing the copying.
Restoring with a backup plugin
If a plugin made the backup, the same plugin usually restores it best, because it knows its own archive format. The usual flow: install WordPress fresh, install the same plugin, upload the archive, run its restore. Check its documentation for the exact steps; plugins differ, and I would rather you follow the vendor’s page than my guess.
A worked example
No client case studies exist on this site yet, so here is a hypothetical one.
Say a host migrates your account to a new server and the site comes up with a database error. You have last week’s backup: a zip of files and a .sql.gz. The restore runs like this:
snapshot the broken state → upload files to an empty public_html → create an empty database and user → import the SQL → update the four DB_ lines in wp-config.php → re-save permalinks → check pages as a logged-out visitor
Anything published after last week’s backup is gone, and that is the honest trade every restore makes. Note what is missing and re-enter it; do not try to merge two databases by hand.
After a hack, a restore is half the job
Restoring a clean backup removes the attacker’s files. It also restores the outdated plugin or the weak password that let them in. Before you call it fixed, update everything, change every password, and remove any spam Google has indexed. Our guide on how to fix a hacked WordPress site covers those steps in order.
Common mistakes
- Database first, files second. WordPress cannot connect until its files and config are in place.
- Importing a Quick export into a database that still has tables. You get errors or a mix of old and new.
- Forgetting
wp-config.php. New database, old credentials, connection error. - Find-and-replace on raw SQL for a domain change. Breaks serialised data in themes and widgets.
- Restoring an infected backup. Check the date against when the problem started.
- Not saving the broken state first. If the backup is bad, you have nothing left.
When there is no backup to restore
Sometimes the zip does not exist: the host closed, the account expired, the only backup lived on the same server. If the site was public, copies of its pages may survive in web archives such as the Internet Archive’s Wayback Machine. A Wayback Press restore rebuilds a site from those snapshots, as static HTML or editable WordPress. My agent picks the best snapshot for each page, fixes layout breaks, drops junk and spam pages, keeps the old URL structure and 301-maps what changed; a human reviews every job before delivery. You can scan the domain and preview the old design, URL structure and a few sample pages for free first. You need to own or have the rights to the content being restored. Wayback Press is not affiliated with the Internet Archive. Pricing starts at $49 for up to 300 URLs, delivered in 3 days on the Starter tier; see pricing.
My stance: if you have a working backup, restore it yourself with the steps above. An archive rebuild is for the day the backup turns out to be a hope.
The file was called backup-final-2.zip. Name the next one with a date.