How to Restore a Website From Backup (2026 Full Guide)

Quick Answer: Learning how to restore a website from backup comes down to order of operations. Copy the current broken site first, choose a restore point from before the problem started, restore the files, import the database, update your database credentials, clear every cache, then test on the live URL before telling anyone it's fixed. A typical shared-hosting restore finishes in 10 to 15 minutes.

Something broke. Maybe a plugin update took the homepage down, maybe someone deleted the wrong folder, maybe there's a redirect on your checkout page that you definitely did not put there. The backup is sitting right there, and the Restore button looks like the answer.

It usually is. But the sequence you follow decides whether you lose an afternoon or lose a week of orders. Our engineers at Hostaccent work through 20 to 30 client issues every day, and a fair share of them are restores that were started in a panic and finished in a mess. This guide is the same process we follow internally, written so you can run it yourself.

Below: what a restore actually replaces, how to choose the right snapshot, the step-by-step sequence, and the three situations that need different handling (a cPanel account, a WordPress site, and a site that was hacked).

What a Website Restore Actually Replaces

A restore is a replacement, not a repair. The saved version gets copied over the live one, and anything created since that snapshot is gone unless you saved it separately. As of September 2026, most shared hosting backups still run once per day, so a restore started at 2pm typically rolls you back to around midnight. That is up to 14 hours of orders, comments, form submissions and uploads, permanently.

A complete website backup normally holds four separate things, and hosts package them differently:

• Files: your theme, plugins, uploads, custom code, .htaccess, and config files like wp-config.php.
• Databases: posts, pages, products, orders, users, settings. For most CMS sites, this is the site.
• Email: mailboxes, forwarders and filters, if your mail runs on the same account.
• Account settings: cron jobs, DNS zone records, FTP users, SSL certificates, subdomains.

Restoring files alone fixes a broken theme edit. It does nothing for a missing product catalogue. Restoring the database alone rolls your content back but leaves a compromised plugin file exactly where it was. Working out which of the four actually broke is what stops you from wiping good data for no reason.

One part almost nobody checks: DNS. If the zone file was restored along with the account, your records can quietly revert to values from weeks ago and the site goes dark for reasons that have nothing to do with the restore itself. Cloudflare's DNS explainer is worth two minutes if you have never opened a zone file.

Also worth saying plainly: a restore does not fix the cause. If a memory limit produced a 500 internal server error, the older files will hit that same ceiling the moment traffic comes back.

Pro Tip: Before you restore anything, download the backup and open it. A job that reports "completed" every night can still be archiving an empty directory if a path changed months ago. A backup you have never opened is a hope, not a plan.

Pick the Right Restore Point: The Three-Question Restore Test

Most failed restores in our queue are not technical failures. They are the right procedure applied to the wrong snapshot. Before you click anything, run what we call the Three-Question Restore Test. It takes about three minutes and it is the difference between a clean rollback and a second incident sitting on top of the first.

Question one: what broke, and exactly when? Check your error logs and your own history. If an update was installed at 14:05 and the site failed at 14:06, the snapshot from that morning is your target. If you cannot pin the time, look at file modification dates in File Manager, sorted newest first. A row of files changed at 3am that you did not touch tells you two things at once: your restore point, and that you may be reading the next section instead of this one.

Question two: what do you lose between that snapshot and now? Orders, form entries, new posts, customer signups. For a brochure site the answer is usually nothing. For a store, it can be the whole reason you cannot use yesterday's backup. Export those tables before you restore, and you get the rollback without the casualty.

Question three: is the backup actually complete? Open it. Confirm it contains both the file tree and a .sql dump with a sensible file size. An 8KB "database backup" is an error message wearing a filename.

Insider Insight: From the Ticket Queue — Hostaccent's own support-queue data (September 2026) breaks down like this: WordPress issues roughly 30% of tickets, brute-force and malware 25%, Linux server issues 25%, SSL problems 20%. That is first-party data from a UK-registered host (Companies House 11431799, incorporated 2018) that has been hosting since 2016 and serves 10,000+ clients worldwide. The pattern behind it: the sites that recover fastest are the ones whose owner knew what their backup contained before they needed it.

Do I really need to keep a copy of the broken site?

Yes, and it is the step people skip most. Take a copy of the current files and database before you overwrite them, even though they are broken. Three reasons: the restore itself can fail halfway and leave you with neither version; the broken site holds the recent data you are about to lose; and if this turns out to be a security incident, those files are your only evidence of how someone got in. A zip in your home directory costs nothing and has saved plenty of weekends.

How to Restore a Website From Backup, Step by Step

The buttons differ by control panel, but the sequence does not. Follow these seven steps in order and the restore works on cPanel, Plesk, or a bare VPS. Skipping step one is how a 15-minute job turns into a three-day rebuild.

1. Take the site offline. Put up a maintenance page or restrict access by IP. You do not want a customer placing an order into a database you are about to overwrite.

2. Copy the current state. Files and database, both, into a dated folder outside your web root. Name it something obvious like broken-2026-09-14.

3. Confirm your restore point. Use the three questions above. Write down the date and time you are targeting so you do not lose track mid-restore.

4. Restore the files first, then the database. This order matters and it is the one the official WordPress backup and restore documentation recommends too. Files first means your application code is in place before the data it expects arrives.

5. Reconnect the two. If the database name, user, or password changed during the restore, update wp-config.php (or your framework's env file) to match. A mismatch here produces the classic "error establishing a database connection" screen, and people often assume the restore failed when it actually worked fine.

6. Clear every cache. Server cache, plugin cache, CDN, and your own browser. In our experience this single step accounts for a large share of "the restore didn't work" tickets. The files are correct; you are looking at a cached copy of the broken page. Cloudflare users: purge everything, then hard-refresh.

7. Verify before you announce it. Load the homepage, one interior page, and one dynamic page (cart, login, contact form). Submit the form. Check that images load, that the padlock is valid, and that admin login works. A restore that brings back a stale .htaccess can produce a 400 Bad Request error on pages that were fine an hour ago.

If your site came back but is now slow or throwing resource errors, the restore worked and the underlying limit did not change: that is a separate problem, covered in our guide to 508 resource limit is reached.

◆ Professional help available

Is this still affecting your store?

Tell us which customer journey is failing and what changed. We can investigate the application, payment, database, and hosting layers without moving your store.

Request store help→Explore eCommerce support↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

Restore a cPanel Backup: Full Account or Just the Broken Part

If you need to restore a cPanel backup, use a partial restore whenever the damage is contained. A full account restore in JetBackup terminates the existing account and recreates it from the snapshot, which means email accounts, cron jobs and FTP users created after that date disappear along with everything else. Partial restores (home directory, single database, single mailbox) take less time, carry far less risk, and are reversible in practice because the rest of the account never moves.

In cPanel you have three routes, depending on what your host installed:

• JetBackup 5: Files → JetBackup 5 → Restore & Download. Tabs for Full Account, Home Directory, Databases, Email Accounts, Cron Jobs, DNS Zones. Pick the tab that matches what broke.
• Backup Wizard: the built-in cPanel tool. Good for restoring a home directory or a single MySQL database from a file you already downloaded.
• File Manager plus phpMyAdmin: the manual route. Upload the archive, extract it in place, import the .sql separately.

Some JetBackup builds offer a "merge backup data with live account data" option on a full restore. Tick it when you want the snapshot's contents added rather than the account wiped and rebuilt. It behaves differently between versions, so check cPanel's official documentation or ask your host before relying on it in an emergency.

When a restore lands in the Hostaccent queue, the first thing we do is ask what changed in the last 24 hours, because the answer usually narrows a full-account restore down to a single directory. Restoring 40GB to fix one corrupted theme file is not caution, it is just slow.

Insider Insight: A full account restore does not preserve anything created after the snapshot, including email that arrived this morning. If mail matters, download the mailbox or export recent messages first. We have watched people recover a website and lose a week of client correspondence in the same click.

Restores also come up during moves between servers, where the same care applies in a different order. Our 12-step guide to moving WordPress to a new host covers that path properly.

Restore WordPress From Backup and Its Database From an SQL File

To restore WordPress from backup manually, you need three things in place: the wp-content folder, a working wp-config.php, and the database. Core files can be re-downloaded from wordpress.org at any time, which means a backup missing wp-includes is annoying rather than fatal. A backup missing the .sql file is fatal, because your posts, pages, products and settings live nowhere else.

The file side is straightforward. Upload your archive to the site root via File Manager or SFTP, extract it, and confirm wp-config.php is present with the correct database name, user and password. Check the $table_prefix line as well: if your backup used wp_ and the fresh install created wpxy_, WordPress will connect to the database and show you a setup screen as though the site never existed.

To restore the database from an SQL backup, phpMyAdmin is the usual route: select the target database, use the Import tab, choose your .sql file. Two things go wrong here constantly. First, the file exceeds the upload limit. Second, the import times out partway through and leaves half your tables populated, which is worse than not starting.

Both have straightforward fixes:

• Compress first. phpMyAdmin accepts .zip and .gz and decompresses on the fly. SQL dumps typically shrink by 70-80%, so a 120MB file often lands under 30MB.
• Raise the ceilings. In MultiPHP INI Editor, increase upload_max_filesize, post_max_size (equal or larger), memory_limit to 512M and max_execution_time to 300. Put them back afterwards.
• Use the command line. With SSH, mysql -u user -p dbname < backup.sql has no browser limits at all. With WP-CLI, wp db import backup.sql does the same job and handles character sets sensibly.
• Drop the old tables first if your dump has no DROP TABLE statements, or you will collect "table already exists" errors on every line.

Watch the collation. Modern WordPress expects utf8mb4, and importing a utf8 dump into a utf8mb4 database is how apostrophes turn into question marks across 400 posts.

Across the 4,000+ site migrations and restores our team has handled since 2016, the step people get wrong most often is not the import itself. It is forgetting that the database stores absolute URLs. If the restore lands on a different domain or a staging subdomain, run a proper search-replace (wp search-replace 'old.com' 'new.com') rather than editing wp_options by hand, because serialised data breaks when you edit it with find-and-replace. Moving between server types adds its own checklist, which we covered in our shared hosting to Linux VPS migration checklist.

Pro Tip: gzip the .sql file before you upload it, even if it already fits. Smaller uploads finish before PHP timeouts become a factor, and a failed import at 90% is genuinely harder to clean up than one that never started.

Restore a Site After a Hack Without Putting the Malware Back

The rules for how to restore a website from backup change the moment malware is involved. The standard advice, restore the most recent backup, is exactly wrong here. Most compromises sit quietly for days or weeks before anything visible happens, which means your newest snapshots are already carrying the backdoor. Restoring one puts you back online for about 48 hours before the same thing happens again.

Here is the order that works when you restore a site after a hack:

1. Preserve the compromised state. Copy files, database and server logs before touching anything. This is evidence, and it is the only record of the entry point.
2. Find the first sign of compromise. File modification timestamps, unfamiliar admin users, unknown plugins, unexpected cron jobs. Work backwards to the earliest anomaly.
3. Restore from before that date, not from last night. If the earliest suspicious file is dated 2 September, your clean snapshot is from late August.
4. Patch the hole before going live. Update core, plugins and themes, rotate every password (hosting, database, FTP, admin, email), and check file permissions. OWASP documents the common entry points if you want to understand what you are closing.
5. Scan the restored site before you lift the maintenance page, not after.

If your clean backup is too old to use because it predates months of real orders, restoring is not your answer and you need a cleanup instead. That is an honest limitation of any backup strategy: a snapshot cannot hold data that was created after it.

One detail people miss: attackers routinely add email forwarders and .htaccess rules that survive a partial restore. If your site is suddenly returning a 403 Forbidden error after a cleanup, a leftover rule in a subdirectory .htaccess is the first place to look. Check every directory, not just the root.

Your Next Step: A Host Where the Restore Is a Ticket, Not a Weekend

Now that you know how to restore a website from backup in the right order, you have two choices: bookmark this page and hope your host's backups are healthier than average, or move somewhere the restore is handled with you. The Economy shared hosting plan at $1.99/mo runs on NVMe storage with free SSL, a 99.99% uptime guarantee, and 24/7 support from our own engineers rather than an outsourced script. One honest caveat: Economy is sized for a single site, so if you are running several client projects, the Standard plan at $4.58/mo is the better fit. Every plan carries a 30-day money-back guarantee, so trying Hostaccent costs you a weekend at worst.

Frequently Asked Questions About Restoring a Website From Backup

How long does it take to restore a website from a backup?

Most shared hosting restores finish in 10 to 15 minutes. Size is the main factor: a small brochure site can be back in under five minutes, while a media-heavy store with tens of thousands of files can run past an hour. Manual restores take longer because the database import is separate. Budget an extra 10 minutes for cache clearing and verification, which is the part people underestimate and the part that determines whether it actually worked.

Do I need a developer to learn how to restore a website from backup?

No. If your host offers a one-click restore in the control panel, it is genuinely a few clicks plus a verification pass, and this guide covers everything else. You need help in three situations: the SQL import keeps failing, the site was hacked and you cannot identify a clean restore point, or the restore would overwrite orders you cannot afford to lose. Those three are worth a support ticket rather than an experiment on a live site.

Will restoring a backup delete the content I added since then?

Yes. A restore replaces your current site with the saved version, so anything created after that snapshot is gone: posts, orders, comments, uploads, user signups. This is why copying the current state first matters so much. If you only need the recent database rows, export those specific tables before restoring, then re-import them afterwards. For a store, exporting the orders table before a rollback is the difference between a small inconvenience and a genuine business problem.

How far back should I restore after a hack?

Further back than feels necessary. Find the earliest file modification, unknown admin account, or suspicious cron entry, then restore from before that date. Malware commonly sits dormant for days or weeks, so last night's backup is often already infected. If your only clean snapshot predates weeks of real data, restoring is the wrong tool and a proper cleanup is the right one. Either way, patch the vulnerability before the site goes back online, or you will be doing this again.

Can I restore just the database and leave the files alone?

Yes, and it is often the smarter move. Restore only the database when your content is wrong but the site works: a bad bulk edit, a deleted page, a plugin that mangled your product data. Restore only files when the code broke but the content is fine, such as a failed theme update. Partial restores are faster, less risky, and far easier to reverse than a full account restore that rebuilds everything you did not need touched.

What if my host only keeps backups for two weeks?

That is common, and it is a real risk on any site where problems can go unnoticed. Two weeks of retention means a slow-burning compromise or a quiet data corruption can outlive every snapshot you have. Keep your own independent copy, stored somewhere other than the server itself, and test a restore occasionally rather than assuming. Hostaccent keeps off-server copies and our engineers can pull an older restore point on request, but the principle holds anywhere: a backup you have never restored is untested.