SFTP/FTP Recovery vs. Hosting Restore: Which Option Saves You Time and Reduces Risk

A hacked WordPress site is stressful, but the next decision is usually what burns time: do you restore from your hosting backup or rebuild the site using SFTP/FTP recovery?

In most real cleanups I’ve done in 2026, SFTP/FTP recovery saves time and reduces risk when you still have access to the server and you can verify what’s changed. A hosting restore is faster only when the backup is clean and you’re sure it matches the moment before the infection.

Below is a clear way to choose between SFTP/FTP recovery vs. hosting restore, with steps you can follow and mistakes to avoid.

SFTP/FTP Recovery vs. Hosting Restore: The direct answer

If you suspect the hack is still present in your WordPress files or your database, SFTP/FTP recovery is often the safer move because you can restore only the infected pieces and confirm each file. If you trust your host’s backup and it’s from a proven clean time, a hosting restore can be faster.

Here’s the simple rule I use on incident calls: restore what you can prove is clean. If you can’t prove it, rebuilding from known-good parts beats “hoping the backup is safe.”

What counts as “SFTP/FTP recovery” (and what it does to your risk)

SFTP/FTP recovery is moving files (and sometimes database dumps) back to a known-good state using SFTP or FTP, then fixing WordPress so it matches the restored content.

SFTP is file transfer over an encrypted connection (SSH-based). FTP is older and not encrypted by default. For cleanup work, SFTP is the safer choice, and many hosts now disable plain FTP or restrict it.

In practice, “SFTP/FTP recovery” usually includes these tasks:

Reviewing what changed (file timestamps, file list size, suspicious directories).
Restoring WordPress core files and trusted themes/plugins from a clean source.
Replacing only the infected files instead of rolling everything back blindly.
Fixing permissions and re-checking for web shell backdoors.
Then cleaning the database if needed (options table changes, injected admin users, cron jobs).

Original insight from my work: the biggest risk with file-only restore is leaving behind “server-side scripts” inside the database-driven parts of WordPress (like cron entries and injected option values). That’s why the best SFTP/FTP recovery plans include a quick database audit even if you start with files.

When SFTP/FTP recovery is the right choice

Choose SFTP/FTP recovery when at least one of these is true:

Your hosting backup is old (for example, it’s daily, and you got hit sometime after midnight).
You have only a partial backup, like files but not the database.
You see clear signs of a backdoor in specific files (a single new PHP file in a weird folder, for example).
You can still log into your server (even if WordPress is broken).
Your host’s restore process is slow or requires ticket support to run.

In one small business case in 2026, the host’s restore window was “up to 24 hours.” The client was infected sometime that afternoon. SFTP/FTP recovery plus a targeted database rollback cut the downtime from about 9 hours to about 2 hours, because we didn’t have to wait on host tooling and we didn’t wipe out changes that were still clean.

What counts as “hosting restore” (and why it can be risky)

A hosting restore means your web host rolls your site back to a saved backup. That can include files, the database, or both—depending on the plan and how the host runs the restore.

Most hosting panels (cPanel, Plesk, custom dashboards) let you choose a backup time. Some hosts also store “snapshots,” which are server-level copies. That can sound great, but it adds risk if the snapshot isn’t truly clean or if it’s missing your recent security fixes.

Hosting restore often includes:

Rolling back the WordPress database to a previous version.
Replacing site files with older copies.
Sometimes restoring server-level settings (or sometimes not).

Key definition: A clean backup is a backup taken at a time when malware and backdoors were not present, and when the backup itself was not infected.

What most people get wrong: they treat “backup exists” as “backup is clean.” I’ve seen backups that were created after attackers already changed files, added admin users, or wrote a web shell. Restoring that backup feels like relief, but it can bring the problem right back.

When hosting restore is the right choice

Hosting restore is the best option when you have a backup you can verify and it matches your incident timeline.

You have automatic backups every hour (or at least every few hours) and you know the approximate infection time.
Your host restore is quick (often under 30 minutes) and well tested.
You don’t have SFTP access or the SFTP user is compromised.
Your WordPress site is too damaged to do a careful rebuild (mass file corruption, broken core files everywhere).
The host provides a “restore with malware scan” option.

Even then, plan for the fact that a restore brings the site back, but it doesn’t automatically remove the reason the attacker got in. You still need hardening and patching after the restore.

How to decide fast: a practical comparison table

Developer comparing a malware recovery decision chart on a laptop

Use this table to choose the best path for your specific situation. The goal is not “which is cool.” The goal is “what finishes the job with the least risk.”

Situation	Best first move	Why it’s safer
Backups are daily and infection happened today	SFTP/FTP recovery	You can restore known-good files while you investigate the exact change window
Host restore is quick and you have hourly snapshots	Hosting restore	You can pick a time close to “before infection”
You find a new PHP file in /wp-content/uploads or similar	SFTP/FTP recovery + targeted cleanup	File-level proof lets you remove the backdoor without rolling back everything
You suspect database injection (new admin users, cron changes)	Either, but verify database either way	Restores can bring back poisoned option values
You can’t trust your host’s backup source	SFTP/FTP recovery with known-good sources	You control what you restore and can verify each component
WordPress is broken everywhere (core files look modified)	SFTP/FTP recovery	You can replace only core files from a clean release while you rebuild

The time trade-off: how long each option usually takes

Time depends on access, backup quality, and how much you need to investigate after the restore. From my experience handling malware cleanup requests, here’s a realistic range.

Typical timelines (real-world ranges)

SFTP/FTP recovery: 1 to 4 hours for file restoration and proof checks, plus 1 to 3 hours for database cleanup if needed.
Hosting restore: 20 to 60 minutes for the restore itself, plus 1 to 3 hours to verify the site and remove any infection that came back.
Verification step for both: 30 to 90 minutes to scan, check users, check cron, and test pages.

Notice the overlap: verification isn’t optional. You can restore and still end up with a site that “looks back online” but has hidden persistence.

Where time gets wasted (and how to prevent it)

The biggest time sink isn’t the restore. It’s the second guessing that happens after the site is back up.

Here are the top reasons teams lose hours:

They restore without isolating the site first, so bots hit it again.
They don’t check for new admin users or changed roles.
They skip cron inspection. Attackers love abusing cron to run their scripts on schedule.
They restore files but leave modified .htaccess or server configs behind.
They don’t rotate credentials after the incident.

If you want a faster path, start with a quick incident checklist and document what you see before you restore. Even a simple notes file helps later when you coordinate with a developer or your host.

Risk trade-off: what gets reinfected after you “fix it”

The risk after recovery is usually not the same risk as the original infection. The second risk is persistence: attackers set up something that survives your first attempt.

As of 2026, many WordPress hacks follow patterns that show up again and again:

Web shells (small PHP files with suspicious obfuscated code).
Malicious plugin or theme files (sometimes renamed to look normal).
Injected admin users with valid-looking permissions.
Changed scheduled tasks via WordPress cron or server cron.
Database option poisoning (site URL changes, plugin settings, redirect rules).

One of the most practical “reduce risk” moves I recommend is to treat the first restored version as a quarantine test, not as your final site. Run a scan, test known pages, and confirm no new scheduled tasks appear.

SFTP/FTP recovery risk points

SFTP/FTP recovery has a few specific risk points:

You can restore files but miss a malicious entry in the database.
You can restore plugins from a “downloaded zip” that someone later tampers with.
You can copy back infected media files from your uploads folder.
You can restore permissions incorrectly and accidentally leave write access open.

To reduce these risks, use clean sources for WordPress core and plugins (official WordPress.org or the vendor’s official download). Then replace uploads carefully: not everything in /uploads is infected, but you need to scan for PHP files and weird executable files.

Hosting restore risk points

Hosting restore also has predictable risk points:

The backup may already be infected if it was created after compromise.
The host may restore files but not fully restore server-level protections.
Your security fixes (WAF rules, plugin changes, file permission tweaks) may be rolled back.
Your credentials may still be exposed if you don’t rotate passwords and keys.

In other words: a restore brings you back in time, but it doesn’t automatically reset trust. Rotating passwords and checking access logs still matters even after a successful restore.

Step-by-step: what I do during SFTP/FTP recovery

IT professional reviewing server files on a computer during SFTP recovery steps

This is a practical flow you can follow if you have SFTP access and you want a controlled recovery.

1) Freeze the attack surface (first 5–10 minutes)

Before you touch files, reduce damage:

Turn on maintenance mode or block traffic to wp-admin temporarily.
Disable suspicious plugins if you can still access wp-admin.
Stop any public cron or job triggers if you have that control.

Even a simple maintenance page helps while you investigate. It also reduces the chance that attackers keep writing changes while you’re working.

2) Identify the change window (timestamps matter)

Check file timestamps and look for “new but strange” folders or files.

Any PHP file under places that never should have PHP is a red flag (for example, random files inside uploads).
Look for tiny PHP files with obfuscated code.
Compare file counts and sizes to a baseline if you have it.

In many cases, the first sign is a small PHP file with a recent timestamp. That’s your best clue for how far back you need to go.

3) Restore known-good WordPress core

Replace WordPress core files with clean ones from the official release for your exact version. Don’t guess the version—check your current install and match it.

This step removes a lot of common infection paths. It also reduces risk from partially modified core files.

4) Rebuild themes and plugins carefully

My default approach:

Remove any plugin/theme that you didn’t install recently, unless you can confirm it’s clean and trusted.
For the rest, reinstall from official sources.
Never copy plugin files from the “infected server” back onto the same server.

If you use a custom plugin, you can’t just download it again. In that case, restore it from your code repo (GitHub/GitLab) or a known-good build artifact.

5) Audit the database (even if you start with files)

X is an account that an attacker usually creates: a new WordPress admin user with a normal username.

Check these areas in the database:

Users table: new admin users, unusual roles, weird password hashes.
Options table: changed values like site URLs, redirect settings, injected script snippets.
Cron jobs: WordPress cron entries that schedule malicious tasks.

After that, remove suspicious scheduled tasks and reset admin users to clean accounts.

Step-by-step: what hosting restore should include (so it doesn’t fail)

If you go with hosting restore, you need a process too. Otherwise you’ll restore the problem back into production.

1) Pick the backup time based on logs

Don’t pick “the closest time” without thinking. If you can, use server logs, page change timestamps, or hosting security alerts to estimate infection time.

If you see file changes at 3:20 PM, choose a backup before that time.
If you can only guess, choose the earliest backup you can safely restore.

2) Restore, then immediately verify

After restore finishes, run quick checks before you put the site fully back online:

Check for admin user changes.
Scan files for known suspicious PHP patterns.
Verify /wp-content and /uploads for unexpected executables.
Check .htaccess and any security-related config files.

This is where hosting restore often “succeeds” visually but fails later. The hidden part is usually in the database or scheduled tasks.

3) Apply security fixes that the restore may roll back

After restoring, repeat your hardening changes. Even good hosts don’t always preserve your security settings across restores.

This is a good place to follow your WordPress security baseline. If you need a starting point, you can pair this with our WordPress hardening tips post (if you’re using our blog cluster) or our guides under Malware Removal.

My recommended decision flow (what I’d do on a real client site)

This is the short version I use during real cleanups when a client asks, “Which saves more time?”

Confirm you have access (SFTP credentials working, database access available, host restore tool working).
Estimate infection time using logs and file timestamps.
If backup is too old (example: daily backups and you suspect same-day infection), start with SFTP/FTP recovery.
If you have frequent snapshots (hourly or more) and you can pick a clean time, a hosting restore is usually faster.
After either option, audit admin users, cron jobs, and suspicious file paths before going live.

One more thing: if you only do file changes and skip database audit, you’re betting against how attackers persist. I’ve cleaned sites where everything looked fixed in files, but the attacker still ran cron tasks every hour.

Security steps after recovery that reduce repeat hacks

Recovery isn’t just “get the site back.” It’s stopping the next infection. In 2026, most repeat incidents happen because the original entry point wasn’t closed.

Rotate everything (yes, even if you restored)

Change WordPress admin passwords.
Rotate database user passwords.
Replace SFTP/FTP passwords and disable unused accounts.
Reissue API keys and remove old credentials in plugins.

Attackers aim for reuse. If the credentials aren’t rotated, a restore can still lead to reinfection.

Close the entry points

Common entry points:

Outdated plugins/themes.
Weak admin passwords.
Exposed wp-admin or login brute force.
File upload abuse (attackers upload a malicious file through a vulnerable plugin).

After you restore, update everything and check access rules. If you suspect brute force, add rate limiting and enable 2FA for admins.

Harden the files that attackers target

One of the fastest wins is to ensure the usual risky paths aren’t writable by the web server unless needed. Use secure file permissions for WordPress directories, and confirm your upload folder doesn’t allow executing PHP files.

If you want more details, our blog has coverage under Website Maintenance and Threat Alerts for the patterns we keep seeing in cleanup jobs.

Case-style examples (so you can picture the outcome)

These are based on patterns I see often, not one-off trivia. They’re meant to help you decide under pressure.

Example 1: “Daily backup” + same-day hack

A local service site gets hit at 2:10 PM. The host has daily backups at 1:00 AM. We restore the previous day first, but then the client loses content changes and still had suspicious cron tasks. SFTP/FTP recovery plus targeted database cleanup fixed the issue faster than repeating restores.

The time saving came from not wiping the day’s clean files and from verifying cron and users right away.

Example 2: Hourly snapshots + clean restore selection

An eCommerce store triggers a malware alert. The host provides hourly snapshots. We chose the snapshot from just before the file change burst, restored once, then ran a full check. The site stayed clean after we rotated credentials and fixed the plugin that allowed file upload.

Here, hosting restore was faster because the backup point was close to “pre-infection,” and verification confirmed the restore was clean.

Bottom line: which option saves you time and reduces risk?

If you can’t prove your backup is clean, don’t rely on it. SFTP/FTP recovery usually saves time and reduces risk when you can restore known-good files, scan for backdoors, and audit the database right away.

If you have frequent snapshots and you can pick a time close to the infection, hosting restore can be faster. Either way, the key is the same: verify admin users, cron jobs, and suspicious files after recovery—then close the entry point so it doesn’t happen again.

If you’re dealing with an active incident right now and you want to avoid the “restore loop,” focus on access and proof. That’s the difference between a quick fix and a repeating emergency.

Featured image alt text: SFTP/FTP recovery vs hosting restore decision checklist for WordPress malware cleanup (2026)

Featured image: Use a simple diagram showing “File audit → Core restore → Plugin/theme rebuild → Database cron/user check → Go live.”