When a website gets hacked, the fastest and most reliable way back to normal is almost always the same thing. Restoring from a clean backup taken before the breach happened, rather than trying to manually hunt down and remove every trace of what an attacker changed.
The problem is that a backup only helps if it actually exists, is recent enough to matter, and is genuinely clean itself. Here is how to set that up properly, before you ever need it.
Why a Backup Strategy Needs to Assume a Breach Will Happen
Some business owners treat backups as protection against accidental deletion or hardware failure alone. A security breach is a different kind of threat entirely, and it changes what “good enough” backups actually look like.
An infected site can quietly compromise every backup taken after the initial breach, since those backups faithfully capture the malicious changes right along with everything else. One documented case involved a business whose daily and weekly backups were both already infected by the time they realized something was wrong, forcing them to abandon restoration entirely and rebuild the site from scratch.
Keep Backups Further Back Than You Think You Need
A breach is not always discovered the moment it happens. Attackers frequently sit quietly inside a compromised site for days or weeks before doing anything visibly disruptive, which means the “most recent” backup at the moment you notice a problem might already be compromised too.
Retain backups going back at least several weeks, not just the last day or two, so you have real options if the infection turns out to predate your most recent copies.
Store Backups Somewhere the Attacker Cannot Reach
A backup sitting in the same environment as your live website is vulnerable to the exact same breach. If an attacker gains broad access to your server, a backup stored right alongside your live files offers little real protection.
Keep at least one backup copy stored off-site, ideally with access credentials and systems separate from your main hosting environment, so a compromise of one does not automatically compromise the other.
Confirm a Backup Is Actually Clean Before Restoring
This is the step that gets skipped under pressure, and it is the one that causes reinfection. A backup is not automatically safe just because it exists. Restoring a backup that already contains a planted backdoor, injected code, or a compromised admin account simply reinstalls the same vulnerability you were trying to escape.
Before restoring, especially after a confirmed breach, look for the signs of a genuinely clean point in time.
- Check backup dates against when the site actually started behaving unusually, not just when you happened to notice.
- Compare file structures, watching for unfamiliar files or unexpected additions around the suspected breach window.
- Review database content for suspicious entries, since attackers sometimes plant malicious content directly inside a database rather than only in files.
If there is genuine uncertainty about which backup is actually clean, restoring to a separate staging environment for inspection first, rather than directly back onto the live site, avoids compounding the problem.
What to Do Immediately After Restoring
Restoring a clean backup removes the immediate infection, but it does not automatically close whatever door let the attacker in the first place.
- Change every password connected to the site, including hosting, admin accounts, database, and FTP.
- Update everything, including your CMS core, themes, and every plugin, since outdated software is the most common entry point for these breaches.
- Remove any plugins, themes, or accounts you do not recognize, since attackers with admin access sometimes create their own way back in.
- Enable two-factor authentication on every account that supports it, closing off the exact kind of access a stolen password alone would otherwise still grant.
Automating Backups So This Is Never a Scramble
Manual backups depend on remembering to actually do them, which rarely holds up consistently over months and years. Automatic, scheduled backups running in the background remove that dependency entirely, so a clean recent copy already exists the moment you need one.
A Breach Recovery Backup Checklist
- Automated backups running on a regular schedule, not manually triggered.
- Backup retention long enough to reach back before a slow, undetected breach
- At least one backup copy stored off-site, separate from the live server
- A process for verifying a backup is clean before restoring it.
- A plan for what happens immediately after restoration, including password resets and updates
Backups Are the Safety Net, Good Hosting Reduces How Often You Need It
A solid backup strategy is essential, but the businesses that experience the fewest breaches in the first place are usually running on hosting with strong baseline security practices already built in.
Ready to protect your website with hosting that takes security seriously from the ground up? HoganHost’s hosting plans include free SSL and built-in security tools, giving your backups a stronger, safer environment to protect in the first place.
