Restoring From a Backup After a Hack: What to Check First

Why a restore alone usually isn't the fix

Restoring a backup removes the malware you can see. It does not remove the reason the malware got there in the first place — an outdated plugin with a known vulnerability, a leaked FTP password, a weak admin credential. If that entry point is still open, restoring a clean-looking backup doesn't end the incident. It just resets the clock. Security teams describe the same pattern over and over: restoring without patching the underlying vulnerability means attackers will use the same door again, sometimes within days of the "clean" restore going live.

Think of it the way you'd think about a break-in: replacing what was stolen doesn't help if the door is still unlocked. The restore replaces the damage. Closing the vulnerability is a separate step, and it's the one that actually prevents a repeat.

Figuring out how far back to restore

Restoring the most recent backup available isn't automatically the right call — if the infection happened three weeks ago and your only backups are from the last two weeks, every one of them already contains the problem. Work backward from evidence, not convenience:

• Compare file-modification timestamps against your backup dates. If you can find the earliest suspicious file — an unfamiliar .php file in wp-content/uploads, a theme file modified on a date you didn't touch it — that timestamp tells you the infection was already present by then. Any backup from that date forward is suspect.
• Check when the symptom first appeared. A Google Search Console flag, a host's spam-abuse email, or the first "Deceptive site ahead" report all carry a date. The infection predates that date, sometimes by weeks, since most of the visible signs show up well after the initial compromise.
• When in doubt, go further back than feels necessary. Losing a few extra days of content changes is a much smaller cost than restoring an infected site a second time.

Verifying a candidate backup is actually clean

A backup's date is a clue, not proof. Before you restore it:

1. Scan the backup file itself for injected code — not just the live site. A malware scanner (or SecurynAI's file-integrity scanning) run against the extracted backup contents will catch what a "this was made before the alert" assumption won't.
2. Spot-check the same high-risk locations a live cleanup would check: wp-config.php, theme files like functions.php, and anything with a .php extension sitting inside wp-content/uploads.
3. Check the database export, not just files. A backup usually bundles a database dump too, and injected content or a tampered wp_options value travels with it just as easily as an infected file does.

If the backup fails any of these checks, go back further. Restoring a backup that merely looks old enough, without verifying it, defeats the point of restoring at all.

What still has to happen after a clean restore

A verified-clean backup gets you back to a known-good state. It doesn't finish the job on its own:

• Update everything before bringing the site back online — WordPress core, every theme, every plugin. Most real WordPress compromises trace back to a known, already-patched vulnerability in something that simply hadn't been updated.
• Rotate every credential the site touches — WordPress admin passwords, hosting control panel, FTP/SFTP, the database password, and any API keys stored in the site (payment gateways, email services, an AI provider key if you use one). Assume anything the compromised version of the site had access to may have been exposed.
• Confirm the specific entry point is actually closed — not just "updated in general." If you know which plugin or credential was the way in, verify that exact issue is resolved, not merely that updates ran.

Reinfection from within the backup window itself

The trickiest failure mode isn't restoring an obviously-infected backup — it's restoring one that looks clean but already contains a dormant persistence mechanism. A scheduled task an attacker created can sit inactive for weeks before it fires again, re-downloading a payload or re-creating an admin account on its own schedule. If that cron entry was created before the backup you chose, restoring that backup brings the timer back with it — and the site can look completely clean for days before the scheduled task runs and the same symptoms return.

This is exactly why "verify the backup, don't just trust its date" matters more than picking the single most recent clean-looking snapshot. When you're not fully sure a candidate backup predates every persistence mechanism the attacker planted, it's worth doing a full manual malware cleanup on top of the restore rather than trusting the restore alone.

When a restore is the wrong first move

There are situations where jumping straight to a restore actively works against you:

• You don't yet know how the attacker got in. If you restore before identifying the entry point, you lose the freshest evidence of what happened — recently modified files, unusual log entries, the exact plugin version that was exploited. Investigate first, or at minimum take a full backup of the infected state, before overwriting anything.
• Every available backup is already contaminated. If your only backups all postdate the infection, restoring any of them just brings the problem back. In that case, a manual clean of the live site — following the same process as our malware removal guide — is the more reliable path, even though it takes longer.
• You need to document what happened. If the site handles customer data and you may owe a breach notification, or if you're reporting to a host or insurer, a premature restore can erase the evidence you'd need to describe the incident accurately later.

A short pre-restore checklist

Before you click "restore," confirm all of the following — skipping any one of them is how a restore turns into a second incident:

1. You've identified, or at least strongly narrowed down, when the compromise actually started.
2. The candidate backup's date is clearly before that window, not just "recent."
3. You've scanned the backup's file contents and database export directly, not just trusted its timestamp.
4. You have a plan to update WordPress core, themes, and plugins immediately after the restore completes — before the site goes back online, if possible.
5. You're ready to rotate every credential the site touches once the restore is confirmed clean.

None of this replaces the deeper cleanup process when you're not confident a clean backup exists — it's specifically for the case where you do have one, and want to use it without recreating the same incident a second time.