Will Restoring a Backup Fix a Hacked Website? Not Usually
By Glenn Lyvers · Updated · 6 min read
Usually, no. Restoring a backup rolls your files back to an earlier date, but on most hacked sites the attacker got in weeks before you noticed anything, so the backdoor and the security hole are sitting inside the backup too. You restore, the site looks clean, and the same door is still unlocked. Often the same malware is back within days.
Restores do have a place in a proper recovery. The trick is knowing exactly what a restore fixes and what it cannot touch.
The timeline problem nobody checks
When I go through server logs on a cleanup, the first malicious request is routinely weeks or months older than the first visible symptom. You noticed the hack on Tuesday. The compromise happened in March.
So which backup are you restoring? Last week's copy has the malware in it. Last month's might too. And many hosts only keep 30 days of backups, which means every copy you have may already be infected. Until you know the actual date of the break-in, restoring is guesswork wearing a seatbelt.
The security hole survives the restore
A backup stores your site exactly as it was, including the outdated plugin with the vulnerability that let the attacker in. Restore it and you have lovingly rebuilt the vulnerable site. The bots that found it the first time still have your address, and automated attacks revisit on a schedule.
Stolen credentials make this worse. If the attacker came in with your admin password, an FTP account, or hosting access, the restore changes nothing about that. They log back in through the front door, politely, with the key you never rotated.
Backdoors age well
Attackers plant their backup plan in the first minutes after breaking in. A backdoor is small: a fake .ico file in wp-content/uploads that is really PHP, three extra lines in a theme's functions.php, a lone file among your mu-plugins. Because it was planted right after entry, it exists in every backup taken since.
Scanning a backup before restoring it helps, and I do recommend it. But the better backdoors are built to look boring, and scanners walk right past them. I find them by comparing files against known-clean originals and by reading what does not belong. That is tedious human work, which is exactly why the backdoors keep working.
Where the infection date actually hides
Since everything depends on the compromise date, it is worth knowing where to look for it. Raw access logs are the best source: the first request to a file that should not exist, the first successful login from an address that is not yours, the first POST to a filename you do not recognize. Many hosts only keep a few weeks of logs, so pull them early, before rotation eats your evidence.
File modification times are the second source, with a caveat. Sorting wp-content by last-modified in your host's file manager often surfaces the planted files immediately, clustered around a single odd hour. But attackers can and do fake timestamps to match the surrounding files, so a tidy-looking date proves nothing on its own. I treat timestamps as a lead, never as an alibi.
The third source is symptoms with dates attached: the first customer complaint, the first Google warning email, the day traffic dipped in your analytics. None of these mark the break-in. They mark the point where hiding stopped working, which is later, sometimes much later.
Your host's backups are not a security feature
Owners often tell me they are covered because the host keeps backups. Host backups are built for a dead server, not for a compromise. They run on the host's schedule, keep a short window, back up the infection along with everything else, and restore the whole account in one motion, backdoors included. They are genuinely useful, and I use them during recoveries. They are just not a plan.
A plan is your own copies, kept for months rather than days, stored somewhere the attacker cannot reach from the website itself. A compromised admin account should never be able to delete your backup history, and with host-only backups it sometimes can.
When a restore is the right move
There are three situations where I reach for a backup myself. A defacement, where the attacker overwrote your pages, restores content quickly while I hunt the entry point separately. A cleanup where malware mangled files beyond sensible repair, where rolling back is simply faster than reconstructing. And the rare, lovely case of a backup that verifiably predates the compromise.
Notice what all three have in common: the restore is one step in a recovery, never the whole recovery. Somebody still has to close the door.
How to restore without reinfecting yourself
- Establish the infection date from server logs, file modification times, or the earliest symptom you can document. Not the date you noticed.
- Pick a backup older than that date. If none exists, accept that you are restoring dirty and plan a real cleanup on top.
- Restore, and immediately update WordPress core, every plugin, and every theme, before doing anything else.
- Rotate every credential the site has ever known: WordPress admins, FTP, hosting control panel, database password, and the salts in
wp-config.php. - Delete plugins and themes you no longer use. Every one of them is a door.
- Scan the restored site, then watch it closely for two weeks.
Skip the middle steps and the restore becomes a scheduled reinfection. The order matters as much as the actions.
One more habit worth stealing: keep the infected copy. Before the restore, download the compromised files somewhere offline. It feels wrong to preserve malware, but that copy is your evidence, and if the site misbehaves again next month, comparing then against now answers questions no scanner can.
What backups are actually for during a cleanup
On my cleanups, backups earn their keep as evidence. Comparing a backup against the current infected site shows me exactly which files changed and when, and that diff usually points a finger straight at the entry point. A good backup habit turns a hack from a disaster into a bad afternoon, just not by way of the restore button alone.
If your backup situation is a shrug and a hopeful look at your host, fix that this week. I wrote a plain-English guide on backup and recovery strategies that covers what to keep and for how long.
And if your site is compromised right now and you are staring at the restore button wondering, run my free site check first, or just hand me the whole problem. Cleaning hacked sites is what I do every day, restore button included, in the right order.
Common questions
Does restoring a backup remove malware?
It removes malware that was added after the backup was taken. The problem is that most compromises start weeks before the symptoms show, so the backdoor and the vulnerable plugin that let the attacker in are usually inside the backup as well. A restore without patching and password rotation typically gets reinfected.
How do I know if my backup is clean?
Establish the infection date first, from server logs or file modification times, and trust only backups older than that date. Scanning the backup helps but is not proof, since well-made backdoors pass scanners. A backup that merely looks fine is not the same as one that predates the break-in.
Should I just delete my website and start over?
For a small site with little content, sometimes that is genuinely the fastest path. But a fresh site inherits the same risks if you reuse old passwords, reinstall the same vulnerable plugin, or import database content carrying injected code. The entry point still has to be understood, or the new site meets the old attacker.
My host restored my site and the hack came back. Why?
Because the restore did not close the entry point. Host restores put files back exactly as they were, including the vulnerability and usually the backdoor. Nobody rotated credentials or patched the plugin that caused it, so the attacker, or their bot, simply walked back in and reinfected the fresh copy.
How far back should I restore after a hack?
Before the compromise date, not before the date you noticed symptoms. Those are usually weeks apart. Check server logs and file modification times to find the earliest malicious activity, then choose a backup older than that. If no backup goes back that far, restore what you have and follow it with a full cleanup.