When Your Backup Is Also Compromised

The three ways a backup fails you in a compromise

Not that it does not exist. That it does not help.

It contains the problem. The compromise happened before the backup was taken, so restoring reinstates it.

It was reachable. The backup sat somewhere the attacker could also reach, and was encrypted or deleted along with everything else.

The entry point is still open. The restore succeeds and the same route is used again within days.

Each of those is preventable, and none of them is addressed by simply having backups.

The detection gap

The central problem. Most small site compromises are not discovered immediately.

An injected script, a hidden page, or a modified file can sit for weeks before anyone notices, and the discovery is frequently indirect: a browser warning, a listing in a security tool, a customer mentioning something odd, or mail suddenly going to junk.

By then, every backup taken since the intrusion contains it. A business keeping seven days of backups, discovering a three-week-old compromise, has no clean copy at all.

That is why retention depth matters more for security than for the accidental-deletion scenario people usually plan around.

What retention should look like

The monthly tier is the one that saves you in the scenario this post is about, and it is the one most small business setups do not have because the default is a rolling window of a few days.

Where the copy has to sit

Somewhere the site cannot reach.

A backup stored on the same hosting account, in a folder alongside the site, is available to anyone who compromises the site. Attackers routinely look for exactly that, because deleting the backups is what makes the situation worse.

What works: a copy held by the hosting provider outside your account, a copy downloaded to your own storage, or a backup service writing to a destination the site has no credentials for.

The principle is that the backup destination should not be writable by the thing being backed up. Where a plugin on the site holds credentials to the storage, those credentials can be taken.

At least one copy that is genuinely offline or immutable is the version that survives the worst case.

Restoring properly

The order matters, and doing it in the wrong sequence produces a second compromise.

1. Take a copy of the compromised state before changing anything, since it is the only evidence of what happened and how.
2. Work out when it started, using server logs and file modification dates, so you know which backups are suspect.
3. Change every credential before restoring: hosting, content system, database, and any account with access.
4. Restore from a backup that predates the intrusion, not the most recent one.
5. Update everything before the site is reachable again, since the entry point was probably an outdated component.
6. Check for what a restore does not remove, including added administrator accounts, scheduled tasks, and mail forwarding rules.

Step six catches the common reinfection. An attacker who added an administrator account or a scheduled task may have persistence that survives a file restore, particularly where the database is restored separately or not at all.

The content problem

Restoring from a month-old backup means losing a month of legitimate changes: new pages, enquiries stored in the database, orders, and comments.

That tension is real and it is why the answer is rarely a straight restore. Frequently it is restoring the code and files from a clean point while carefully preserving current data, which is more work and produces a better outcome.

Where enquiries or orders live only in the site's database, that is worth knowing in advance, since it determines how much a clean restore actually costs. Forwarding enquiries to an inbox as well as storing them means a restore never loses them.

The test worth doing

Not whether backups are running, which the dashboard already says.

Whether you can identify what your oldest available backup is, whether you could restore it, and whether it sits somewhere your website cannot reach. Three questions, answerable in ten minutes.

Most small businesses find at least one uncomfortable answer, usually that the oldest copy is a week old and it lives on the same account as the site, which is the arrangement that fails in exactly the case it was meant for. What to do in the first hours of finding out is covered in the day after a site is compromised.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.