Restoring from a backup is straightforward once, and it goes wrong when people restore more than they needed to. A site broken by a bad update needs its files; restoring the database alongside them discards every order and comment since the backup.
Decide what is actually broken before you restore anything.
The four parts of a WordPress site
Core files: replaceable from an official download, identical for everyone.
wp-content: your themes, plugins and uploads. This is the part that cannot be downloaded again.
wp-config.php; the database credentials and keys for this installation.
The database: posts, pages, settings, users, orders.
Most restores need one or two of those, not all four.
Back up the broken state first
Before restoring anything, take a copy of the site as it is now.
It sounds pointless when the site is broken. It is what lets you recover data that arrived after the backup, and what lets you undo a restore that turns out to have been the wrong choice; a restore is not reversible on its own.
Restoring files only
The right move when a plugin, a theme or a core update broke the site and no content is missing.
Replace the affected directory from the backup. The single plugin, or the theme, or core, and leave the database alone.
Do not restore wp-config.php from an old backup unless you know it matches the current database credentials. An old config with an old password is the fastest way to turn a broken site into a site that cannot connect at all. How to Fix Error Establishing a Database Connection sets out that error.
Restoring the database
The riskier direction, because it discards everything written since the backup.
In phpMyAdmin, select the database, drop the existing tables, then import the SQL file. Importing over existing tables without dropping them merges the two, which produces a database in a state that never existed.
Export the current database first, even though it is broken. On a shop, that export is the only record of the orders you are about to discard, and merging them back afterwards is possible only if you kept it. How to Manage MySQL Databases with phpMyAdmin walks through both operations.
Large databases fail in the browser
phpMyAdmin imports through a web request, and a large SQL file exceeds the upload or execution limits.
Two ways round it. Raise the PHP limits temporarily: both upload_max_filesize and post_max_size, since one without the other does nothing, or import from the command line, which has no such limits and is faster.
A partial import is worse than a failed one, because it leaves the database half-restored. If an import stops midway, drop the tables and start again rather than re-running it. There is more on getting a shell in cPanel Terminal and SSH Access.
Restoring to a different address
A backup restored to a staging domain, or to a new host before DNS moves, carries the old address inside it.
The site address setting is the small part. The larger part is every image URL and internal link stored in your content, which still points at the original domain.
That needs a search and replace across the database, and it cannot be a plain SQL REPLACE: serialised data records its own lengths and a plain replace corrupts it, which shows up as theme settings reverting to defaults. How to Change Your WordPress Site URL walks through doing it safely.
After any restore
Four checks, in this order.
Save permalinks without changing anything, so the rewrite rules are regenerated. A restored site with stale rules 404s on every page but the homepage.
Load a post, an archive and a page: each can break independently.
Check images on an older post, which is where content-stored addresses show up.
Log in to the admin area and confirm the user list is what you expect.
If the restore is because of a compromise
Restoring clean files does not close the way in.
A site restored to a version from before the compromise is a site with the same vulnerability, and it is reinfected within days. Update everything, change every credential, and find the entry point before putting it back online. For the order, see How to Clean Up a Hacked WordPress Site.
Note also that a backup taken after the compromise contains it. Check the date of the incident against the date of the backup before trusting it.
Practise once, deliberately
Restore a backup to a test location while nothing is wrong.
That is what finds the problems that only appear at restore time: a backup excluding a directory, a database too large to import, a job that stopped running weeks ago. Finding any of those during an outage costs hours. How to Manage WordPress Backups deals with what should be running.
When there is no backup at all, more usually survives than people expect. How to Recover a WordPress Site with No Backup walks through where the copies are, in the order worth checking.
Establish which part is broken before restoring anything
Restoring everything because one component failed discards work that was fine, and a minute of checking narrows it.
wp db check 2>/dev/null | tail -3
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-login.php
ls -la wp-content/themes/ wp-content/plugins/ | head -20
tail -30 ~/logs/example.com.error.log
A site returning a database connection error needs the database and not the files. A site with a fatal error naming a plugin needs that plugin and not the database. A blank page with a clean log is usually a memory or a configuration problem, and restoring anything at all would have been the wrong move.
The error log is the fastest route to the answer and the step most often skipped in favour of restoring the whole thing.
Restore the database from the command line
Browser based import is where large restores fail, and the command line has none of those limits.
gunzip < backup.sql.gz | mysql -u dbuser -p dbname wp db import backup.sql wp db size --tables --human-readable | tail -10
Read the last command afterwards. A table that is dramatically smaller than expected means the import stopped partway, which happens silently when the dump was truncated or a statement exceeded a limit.
Import into an empty database rather than over an existing one where possible. Importing over the top leaves any table that was not in the dump exactly as it was, which produces a mixture of two states that is harder to reason about than either. Managing MySQL databases with phpMyAdmin covers the interface route.
Confirm the site is the version you meant to restore
A restore that completes without error can still have produced yesterday's site when you wanted last week's.
wp post list --post_type=post --field=post_date --posts_per_page=3 wp option get siteurl; wp option get home wp plugin list --status=active --field=name | head
Check the date of the most recent content against when the problem started. If the newest post is after the point at which things broke, you have restored a backup that already contains the fault.
That is the single most common wasted restore, and it happens because the newest backup is the one people reach for. The right backup is the newest one from before the problem, which requires knowing when the problem began.