When You Need to Restore
Knowing how to restore a WordPress backup is the skill that turns a backup from a file gathering dust into a real safety net. A backup you cannot confidently restore is only a hope. Restoring means taking that saved copy of your site and putting it back in place so the live site returns to the working state it was in when the copy was made. It is the other half of backing up, and it is the half people practice least, which is exactly why so many restores go badly under pressure.
There are a handful of situations where you will reach for a restore, and it helps to recognise them, because each one changes how careful you need to be.
A hack or malware infection
If your site has been compromised, restoring a clean backup from before the intrusion is often the fastest way back to a working, trusted site. The important caution is that a restore alone does not fix a hack. If the weakness that let the attacker in is still there, they will simply walk back in through the same door. Restore to recover the clean content, then immediately close the hole. Our guide on how to fix a hacked WordPress site covers the full cleanup, and the WordPress security guide covers hardening so it does not happen again.
A failed update or a bad change
Updates usually go smoothly, but every so often a plugin, theme, or core update clashes with something and leaves you with a broken layout, a white screen, or a feature that no longer works. A recent backup lets you roll the whole site back to the moment before the update and try again more carefully. The same is true after a botched edit, a plugin that corrupted content, or a redesign that went wrong.
A migration that needs undoing
When you move a site to a new host or a new domain, a backup of the original is your way back if the migration does not go as planned. Restoring the original gives you a clean starting point to try the move again without having lost anything.
A host failure or data loss
Servers fail, accounts get suspended, and files occasionally vanish for reasons that are nobody's fault. If your host loses your data, or you lose access to it, an off site backup is what lets you rebuild the site somewhere else instead of starting from scratch. This is the disaster people insure against without ever expecting it to happen.
Human error
The most common reason of all is simply a mistake. Someone deletes the wrong page, overwrites the wrong file, empties the wrong table, or wipes content that took months to build. A backup means an honest mistake is a five minute fix rather than a week of rebuilding. If you have not set backups up yet, start with our companion guide on how to back up a WordPress website, because you cannot restore what you never saved.
What a Full Restore Includes
Before you restore anything, it helps to understand what a WordPress site is actually made of, because a real restore has to put back two separate things. Miss either one and the site will not work.
The files
The files are everything that lives on the server as actual documents: the WordPress core files, your theme, your plugins, and your uploads folder, which holds every image, PDF, and media file you have ever added. Files are what your host stores on disk. When people picture a website, they are usually picturing the files. A full backup includes all of them, and a full restore puts them all back.
The database
The database is the part people forget, and it is where most restores go wrong. Your posts, pages, comments, users, categories, menus, widget settings, and nearly every configuration choice live in the database, not in files. The database is the memory of the site. You can restore every file perfectly and still have an empty, broken site if you do not also restore the database, because there would be content and no record of it, or a record and no content.
This is the single most important idea in restoring: a WordPress site is files plus a database, and a proper restore returns both, matched to the same point in time. A backup taken at ten in the morning has files and a database that agree with each other. If you restore ten o'clock files against yesterday's database, they can disagree in ways that break things. Keep the two halves together.
Before You Restore: Preparation
A restore overwrites your live site with an older copy, which is a powerful and slightly dangerous thing to do. A few minutes of preparation prevents the most painful mistakes, and skipping them is how people turn one problem into two.
Back up the current state first
This sounds odd when the site is already broken, but take a fresh backup of the site as it is right now before you restore over it. The current state, broken as it may be, contains anything added since your last good backup, and it is your only way back if the restore itself goes wrong or restores the wrong copy. A restore is a one way door unless you have kept the room behind you.
Confirm you have the right backup
Identify exactly which backup you intend to restore and confirm it covers the moment you want to return to. If the site was hacked on Tuesday, you want the last clean backup from before Tuesday, not Wednesday's copy of the already infected site. Check the date, and if you can, check that the backup contains both files and a database.
Know your details
Have your login details ready: hosting control panel, SFTP or FTP credentials, and database access. If you are restoring manually you will need the database name, username, and password from your site's configuration file. Gathering these first means you are not hunting for passwords in the middle of the job.
Put the site into maintenance mode
If the site is live and reachable, switch on a maintenance or coming soon mode so visitors see a tidy message rather than a half restored site flickering in and out. This is especially important for a store, where a customer hitting a broken checkout mid restore is a lost sale and a bad impression.
Do not restore in a panic
The strongest advice is to slow down. Most restore disasters come from acting fast and skipping the fresh backup or restoring the wrong copy. Read the whole process once, make your safety copy, and then proceed calmly. A restore done carefully takes a little longer and goes right the first time.
Restoring With a Backup Plugin
If you used a backup plugin to create your backups, restoring with the same plugin is by far the easiest route, and it is the one we recommend for most site owners. The plugin knows how to put both the files and the database back, in the right order, without you touching the server directly. This is the whole point of a good backup plugin: it makes the restore as painless as the backup.
Restoring from within WordPress
When your site still loads and you can reach the dashboard, restoring is usually a matter of opening the backup plugin, finding the backup you want in its list, and clicking restore. The plugin unpacks the files, imports the database, and swaps everything into place. It will often warn you that the current site will be replaced, which is your cue to be sure you took that fresh backup first. Within a few minutes the site returns to the state it was in when the backup was taken.
Restoring when the site will not load
The harder case is when the site is so broken you cannot reach the dashboard to run the plugin. Good backup plugins plan for this. Some provide a separate small restore script you upload to the server that rebuilds the site from a backup file without needing a working WordPress install. Others let you reinstall a fresh, empty WordPress, add the plugin again, point it at your backup file stored off site, and restore from there. The exact steps depend on the plugin, so check its documentation, but the principle is the same: you do not need the broken site to be working in order to restore over it.
Where the backup file lives
If your backups were stored off site, in a cloud account rather than on the server, this is where that choice pays off. A backup sitting only on the same server can be gone along with the site if the server fails. An off site backup is reachable no matter what happened to the site, which is exactly why we push people to store backups somewhere separate. The plugin reconnects to that storage, pulls the backup down, and restores it.
The reason we favour plugin restores for most sites is simple: they handle the fiddly, error prone parts, matching files to database and rewriting the pieces that need to change, so you do not have to. For a site owner who is not comfortable editing files on a server, this is the safe path.
Restoring Manually With SFTP and phpMyAdmin
Sometimes you have to restore by hand: the backup is a plain set of files and a database dump with no plugin behind it, the plugin cannot run, or you are rebuilding on a fresh server. A manual restore is more involved, but it is not mysterious once you see it as two jobs done in turn: put the files back, then put the database back, then make the two agree.
Step one: restore the files with SFTP
SFTP is the secure way to move files between your computer and the server. Using an SFTP client and the credentials from your host, connect to the server and open the folder where WordPress lives, usually the public web root. If a broken or infected set of files is there, the cleanest approach is to remove the old WordPress core and plugin files first, then upload the files from your backup in their place. Be careful to keep the uploads folder and the configuration file matched to the same backup so images and settings line up. Uploading a full site over SFTP can take a while because there are many small files, so let it finish completely before moving on.
Step two: restore the database with phpMyAdmin
The database usually comes as a single export file, often ending in a .sql extension. phpMyAdmin is a tool most hosts provide for managing the database through the browser. Open it from your hosting control panel and select the database your site uses. To restore cleanly, it is best to empty the existing tables first, by dropping them, so the import is not fighting old data. Then use the import function to upload your backup's .sql file. phpMyAdmin recreates every table and fills it with your saved content. For a large database the import can take a minute or two, and very large ones may need to be handled in pieces or through a command line tool if the browser upload limit gets in the way.
Step three: make files and database agree
The final step is the one people skip, and then wonder why the site is broken. WordPress connects to the database using the details in the configuration file, so those details, the database name, username, password, and host, must match the database you just restored into. If you restored into a database with different credentials, update the configuration file to match. If you moved the site to a new domain or a new server address, the database will still contain the old address in many places, and the site can misbehave until those are updated to the new one. On a same site restore to the same domain this is not needed, but on any move it is essential.
Manual restores reward patience and punish rushing. Work through the three steps in order, check the site after each, and you will get there. If any of this feels beyond your comfort, that is a completely reasonable reason to hand it to someone who does it daily rather than risk making the situation worse. The official WordPress guide to restoring your database covers the phpMyAdmin steps in detail.
Restoring on a New Host
Restoring onto a new host is really a restore and a move combined, and it comes up when you are changing providers, recovering from a host that failed you, or rebuilding after an account was suspended. The good news is that a backup is exactly what you need to do it, because a backup is a portable copy of the whole site.
The shape of the job is to set up an empty home on the new host, restore the files and database into it, point the configuration at the new server's database, and then update the domain so it sends visitors to the new place. If you used a backup plugin that supports migration, much of this is handled for you: you install the plugin on a fresh WordPress on the new host, feed it the backup, and it restores and adjusts the site to its new home in one motion. Doing it manually follows the same file and database steps as above, with extra attention to the configuration and to any place the old server address is stored.
A few things make a host move go smoothly. Restore and test the site on the new host before you switch the domain over, so you are checking a working copy rather than debugging in public. Because a domain change takes time to spread across the internet, keep the old host running until the new one is fully live and confirmed, so nothing goes dark in between. And go through the site afterward checking links, images, and forms, since these are where small mismatches show up first. Because this overlaps so much with migration, our dedicated guide on how to move WordPress to a new host walks through the whole move end to end, including the domain and testing steps.
Restoring Only Part of a Site
Not every problem needs the whole site rolled back. Sometimes only one piece is broken, and restoring everything would throw away good work made since the backup. A partial restore fixes the broken piece while leaving the rest of the site as it is. This is a more surgical operation and it needs a clear head, but it is often the better choice.
Restoring the database only
If your content is the problem, a page was deleted, a table was corrupted, settings were wiped, but the files are fine, you can restore just the database from a backup while leaving the current files in place. This brings back your content and settings without touching the theme and plugins. The catch is that files and database can drift apart: if you installed a plugin after the backup, restoring an older database may leave the plugin's files present but its settings missing. Weigh whether the content you recover is worth the mismatch you introduce.
Restoring the files only
The reverse case is when your content is fine but a file is broken: a theme file got mangled, a plugin's files were corrupted, or core files were tampered with. Here you can restore just the affected files, or the whole file set, while leaving the current database untouched, so no content is lost. This is common after a partial hack that changed files but not the database.
Restoring a single file or folder
The most targeted restore of all is pulling one file or one folder out of a backup and putting it back, without disturbing anything else. If someone deleted an image, or one plugin's folder got damaged, you can open the backup, take just that piece, and drop it into place over SFTP. This is quick and low risk because you are changing only what is broken.
Restoring one deleted page or post
Occasionally you only need one piece of content back, a single page or post that was deleted. Rather than restore the entire database and lose everything created since, it is often better to spin up the backup as a separate copy, find the content you need there, and copy it into the live site by hand. It is more manual, but it recovers the one thing you lost without undoing everything else.
Partial restores are powerful but demand that you understand the files and database split from earlier, because the whole risk is the two halves disagreeing. When in doubt, a full restore onto a staging copy, where you can pick out exactly what you need, is the safer route.
Test on Staging First
Whenever the situation allows it, restore onto a staging copy of your site before you restore over the live one. A staging site is a private clone of your site where you can try things without any visitor ever seeing them. Restoring to staging first turns a nervous, high stakes operation into a calm rehearsal.
The benefit is that you get to confirm the restore actually works before you commit to it. You can check that the backup is complete and not corrupted, that the content came back, that images load and forms work, and that nothing is broken, all on a copy that does not matter. If the restore has a problem, you find it on staging where it costs nothing, not on the live site in front of customers. Only once you have seen the restore come back cleanly do you repeat it on the live site, now confident it will work.
Staging is also the right place to test the fix that goes with a restore. After a hack, for example, you can restore the clean backup to staging, apply the security fixes, confirm everything holds, and then move that verified result live. This turns recovery from a leap of faith into a checked, deliberate step. If you do not have a staging environment yet, our guide on how to create a WordPress staging site shows how to set one up, and many good hosts provide staging with a single click.
There is a wider habit hiding in here that is worth naming. The only way to truly know a backup works is to restore it, and staging is the safe place to do exactly that. Restoring a backup to staging every so often, even when nothing is wrong, is how you discover a broken or incomplete backup on a quiet afternoon rather than during a real emergency. A backup you have restored at least once is a backup you can trust.
Common Restore Errors and Fixes
Restores hit a familiar set of snags. Recognising them saves a lot of anxiety, because most look alarming and are simple to resolve once you know what they mean.
| What you see | Likely cause | What to do |
|---|---|---|
| Error establishing a database connection | The configuration file's database details do not match the restored database | Update the database name, user, password, and host in the configuration file to match |
| White screen, no content | A broken file, a plugin conflict, or an incomplete file restore | Re-upload the files, check the error log, and temporarily disable plugins |
| Site loads but content is missing | The database was not restored, or only the files were put back | Restore the matching database so files and content agree |
| Images broken after a move | The old site address is still stored in the database | Update the stored site address to the new domain across the database |
| Import fails or times out | The database file is larger than the upload limit allows | Import in smaller pieces or use a command line tool instead of the browser |
| Styling gone, plain text page | Files and database are from different points in time, or theme files are missing | Restore both halves from the same backup and confirm the theme files uploaded |
| Login no longer works | Users table restored from an older backup with a different password | Use the older password, or reset it through the database or a recovery link |
Two themes run through almost all of these. The first is the files and database split: most breakage comes from the two halves disagreeing, so when something looks wrong after a restore, check that both came from the same backup. The second is the stored site address: after any move, the old address lingers in the database and causes broken images and odd redirects until it is updated. Keep those two ideas in mind and you will diagnose the large majority of restore problems quickly. When an error message mentions a specific file or function, the site's error log is the fastest way to see what actually went wrong, and the WordPress debugging documentation explains how to turn it on safely.
Preventing the Need to Restore
A restore is a recovery, and the best kind of recovery is the one you never have to perform. Everything that reduces the chance of a disaster reduces how often you reach for a backup, and the habits are the same ones that keep a site healthy generally.
The practical habits are these. Back up regularly and off site, so that when you do need a restore, a recent clean copy is waiting. Test updates and big changes on staging before they touch the live site, so a bad change never reaches your visitors. Keep the site secure and current, because most emergency restores follow a hack or a failure that hardening would have prevented, which our security guide covers in full. And keep the site maintained, so small problems are caught and fixed before they grow into the kind of disaster that only a restore can undo. Ongoing care is the quiet work that keeps the dramatic recoveries rare.
Think of it as two layers. Prevention keeps most disasters from happening at all, and a tested backup means the rare disaster that slips through is a recoverable inconvenience rather than a catastrophe. You want both. A site with good backups and no prevention is always fighting fires; a site with prevention and no backups is one bad day from losing everything. Together they are what a professionally run site looks like.
When to Get Help
Plenty of restores are well within a confident site owner's reach, especially a plugin restore back to the same site. But there are moments when handing it to a team that does this daily is simply the wiser call, and there is no shame in it. Restoring under pressure, on a site that earns money or holds customer data, is exactly when a steady, experienced pair of hands is worth the most.
It is worth getting help when the site will not load and the plugin route is not working, when a restore has to be done by hand on the server and you are not comfortable there, when you are restoring onto a new host and juggling the domain at the same time, or when the restore is tangled up with a hack that also needs cleaning and hardening. In each of these the cost of a mistake is high and the margin for error is small, and a wrong move can turn a recoverable situation into a lost one.
We restore WordPress sites, clean up after hacks, and move sites between hosts, and because we are developers we can handle the harder cases that a plugin alone cannot: a corrupted database, a site too broken to reach, a restore that has to be pieced together from incomplete backups. We can also set up proper backups and a tested restore plan afterward, through our WordPress maintenance service, so the next scare is a five minute fix. You can see the range of what we handle on our services page, and our pricing page explains how we work.
If you need a site restored, or you want to be sure your backups would actually work when you need them, you can get a free quote and we will take a look and tell you honestly where things stand. Or book a free consultation and we will talk it through with no obligation. Restoring is the moment a backup proves its worth, and having someone in your corner who has done it a hundred times turns a stressful day into a solved problem.