How to Restore a Website From Backup (and Test It First)
Something has gone wrong: a bad plugin update, a hack, a botched migration, or you deleted the wrong folder at 11pm. You have backups. Now comes the part nobody explains properly, which is that restoring a backup badly can do more damage than the original problem, especially if you skip testing and push it straight onto a live site.
This covers how to pick the right restore point, test it somewhere safe first, and then bring it live without losing anything you didn’t mean to lose. It sits alongside the rest of GoodHost’s security and backups guides for when things go wrong more broadly.
Short answer: Identify the most recent clean backup before the problem started, restore it to a staging environment or temporary URL first, check the site actually works there, then restore it to the live site. Never restore an unverified backup directly onto a live, working site.
How do you choose the right backup to restore?
Pick the most recent backup taken before the problem appeared, not simply the most recent one available, since the latest nightly backup may already contain the fault if it happened before that backup ran. Work backwards from when you first noticed the issue.
If you’re not sure exactly when something broke, check a few candidate dates rather than guessing once. A hack, in particular, can sit dormant for days before it’s noticed, so the last known good backup might be older than you’d expect.
- What date did the problem first appear, or was first reported to you?
- Does your backup system keep more than one recent copy, or only the latest?
- Is the backup a full site backup (files and database) or files only?
- Was anything legitimate added to the site after that date that you don’t want to lose?
That last point matters more than people expect. If a customer placed an order or a form submission came in after your chosen restore point, restoring will wipe it unless you extract that data separately first.
Why should you test a restore before going live?
Testing first catches problems while nobody is looking, rather than in front of live visitors. A restored backup can fail to load correctly if the database and files are from slightly different points in time, if file permissions come through wrong, or if the backup itself was silently incomplete, and none of that is obvious until you actually open the site.
The safest way to test is a staging copy: a duplicate of the site on a subdomain or temporary URL that visitors and search engines never see. Restore the backup there first, click through the key pages, log in as admin, check the shop or contact form if there is one, and only then move to the live site.
If your host doesn’t offer one-click staging, a temporary subdirectory or a separate test domain works the same way. The point is simply that nothing goes near the live URL until you’ve confirmed it actually works.
What’s the actual restore process?
The mechanics differ depending on whether you’re restoring through a hosting control panel, a backup plugin, or manually via FTP and phpMyAdmin, but the sequence is broadly the same across all three: take a fresh backup, restore to staging first, test it properly, then restore to live.
| Step | What happens | Why it matters |
|---|---|---|
| 1. Take a fresh backup of the current (broken) state | Snapshot before you touch anything | You can undo the restore itself if something goes wrong |
| 2. Restore files to staging | wp-content, themes, plugins, core files | Confirms the file side is intact |
| 3. Restore the database to staging | Content, settings, user accounts | Confirms data integrity separately from files |
| 4. Test on staging | Click through pages, log in, check forms | Catches problems before visitors see them |
| 5. Restore to live | Repeat steps 2 to 3 on the production site | Only once staging is confirmed working |
| 6. Verify live and clear caches | Check the live URL directly, purge any CDN or caching layer | Old cached pages can mask a successful restore |
On GoodHost’s cPanel plans, JetBackup handles emergency restores directly through the control panel, and daily backups mean there is usually a same-day or next-day restore point available without needing a separate backup plugin running on the site itself.
What if you don’t have a recent enough backup?
This is the situation nobody wants, and it’s more common than it should be. If your available backups are all older than you’d like, or nonexistent, you’re weighing a partial restore against no restore at all, and neither option feels good in the moment.
Restoring an old backup at least gets a working site back online, even if it means manually re-adding whatever changed since then. Compare that against the cost of extended downtime while you try to reconstruct things by hand from scratch, which usually takes longer and rarely produces a cleaner result.
- Restore the newest available backup, however old, to get something live
- Check whether your database still has newer data recoverable separately (some hosts retain database snapshots even without a full file backup)
- Manually re-enter anything you can reconstruct from records, emails or screenshots
- Set up a proper backup schedule immediately afterwards so this doesn’t repeat
If this has happened to you, it’s worth reading how often a website should actually be backed up once the immediate fire is out, since the right frequency depends on how often your content changes.
How do you know the restore actually worked?
A restore that looks fine on the homepage can still be broken underneath. Check more than just the front page: log into wp-admin or your CMS dashboard, place a test order if it’s a shop, submit the contact form to yourself, and check that images and menus render correctly on a couple of interior pages, not just the homepage.
If the site was down because of a hack rather than a simple error, restoring a backup brings back the vulnerability too unless you also close whatever let the attacker in originally. A restore undoes the damage; it doesn’t undo the entry point.
For that reason, if a hack is what caused this, it’s worth working through what to do in the first hour after a hack alongside the restore, rather than treating the restore as the whole fix.
Frequently asked questions
Can I restore just the database without restoring the files?
Yes, and it’s often the right move if only content or settings are wrong but the files themselves are fine. Restoring files and database together is only necessary when both are suspected to be affected.
Will restoring a backup change my domain or DNS settings?
No. A standard site backup covers files and database, not domain registration or DNS records, so those stay as they are unless you separately edit them.
How long does restoring a website from backup usually take?
It depends heavily on site size and method: a small site through a control panel tool can take minutes, while a large site restored manually via FTP and phpMyAdmin can take considerably longer.
What happens to orders or form submissions made after the backup date?
They’re lost from the restored version unless you extract that data separately beforehand, since the restore rolls the whole site back to the state it was in at that backup’s point in time.
Should I restore to the live site directly if I’m confident the backup is good?
It’s still worth testing on staging first even when you’re confident, because file permission issues and partial backups are not always visible until the site is actually loaded and clicked through.
If you want to see exactly what a full restore looks like on GoodHost’s cPanel plans before you need one for real, the security page covers what’s included, including how JetBackup’s emergency restores work day to day.