Backups an Attacker Cannot Reach

The threat this addresses

Ordinary backup advice assumes the failure is accidental: a bad update, a mistaken deletion, a disk failing.

Against those, a copy on the same server is adequate and frequently sufficient.

Against somebody who has gained access, it is not, because they have the same reach you do.

An intruder deleting or encrypting the backups is not an exotic scenario, it is the standard approach, since backups are the thing that makes the rest of the attack pointless.

Where backups are reachable

• On the same server as the site.
• In a folder the website can write to.
• In cloud storage the plugin has full access to.
• Held only by the host, in the same account.
• On a drive permanently connected to a machine.

The third catches people who did everything right. A backup plugin sending copies to cloud storage holds credentials with permission to delete, so somebody inside the site inherits that permission.

The three properties that matter

Stated plainly, since the advice is usually given as a slogan.

Offsite, meaning not on the machine being backed up, so losing the server does not lose the copies.

Versioned, meaning several restore points going back weeks, so a problem discovered late can still be undone.

And out of reach, meaning at least one copy that credentials on the server cannot alter or delete.

Most small businesses have the first, sometimes the second, and almost never the third.

The third is the one that matters specifically against an intruder, and it is the one that requires a deliberate arrangement rather than a setting.

Versioning matters more than people think

Because compromises are usually discovered weeks after they happen.

A backup system keeping seven days is useless if the site was compromised a month ago, since every copy you hold contains the problem.

That is the common failure and it is invisible until the moment it matters.

Keep daily copies for a fortnight, weekly for a couple of months, and monthly for a year, which is a standard arrangement and is not expensive at the size of a small business site.

The cost of storage is trivial against the cost of discovering that every restore point is contaminated.

Getting a copy out of reach

The practical options, in order of how easy they are.

Give the backup credentials write-only permission where the storage supports it, so the plugin can add copies and cannot delete them.

Use storage with a retention setting that prevents deletion for a defined period regardless of who asks.

Or take a manual copy periodically to a machine or drive that is not connected to anything, which is unfashionable and works.

A monthly download to a laptop, kept somewhere sensible, is a genuine out-of-reach copy and takes ten minutes.

For most small businesses that manual monthly copy is the realistic answer, since the permission arrangements require someone comfortable configuring storage.

A worked example

A business had nightly backups going to cloud storage, kept for thirty days, and considered themselves well covered.

After a compromise, the intruder used the credentials stored in the site's backup plugin to delete the entire storage bucket.

Everything was gone in one action, including the thirty days.

What saved them was a copy the owner had downloaded manually about six weeks earlier before a redesign, sitting on a laptop.

It was out of date and it was a site rather than no site.

Afterwards they changed the plugin credentials to write-only and added a monthly manual download, which was the arrangement they had assumed they already had.

Back up more than the site

Since restoring a website does not restore a business.

The database and the files, which most people cover.

Email, which frequently lives only in the provider and which most businesses have no copy of at all.

Customer records, invoices, and accounting data, wherever they live.

Photographs, which are usually the least replaceable thing a small business holds and the least backed up.

And the configuration details that make a restore possible: where the domain is registered, which host, and who holds the accounts.

Check what you actually have

The audit, which takes half an hour and is frequently uncomfortable.

Find where the backups are stored and confirm you can reach them yourself, without the plugin.

Check how far back they go, which is usually less than assumed.

Check whether the credentials that write them could also delete them.

Download one and open it, confirming it contains what you expect rather than an empty archive.

Then note where all of this lives, since the person who knows may not be available when it is needed.

The host's backup is not yours

A distinction worth drawing, since many businesses rely entirely on it without knowing the terms.

Host backups are usually taken for the host's benefit rather than yours, kept for a short period, and offered as a courtesy rather than a guarantee.

They also live in the same account, so a suspended or closed account can take the backups with it, which is exactly the situation where you need them.

Ask your host three questions: how often, how far back, and whether you can download a copy yourself without asking them.

Where the answer to the third is no, the host's backup is a convenience and you still need your own.

The counter-case

This can be overbuilt.

A simple brochure site with no customer data and a copy at the host is adequately protected, since rebuilding it is a day's work rather than a crisis.

Elaborate arrangements also fail more often than simple ones, because nobody maintains them, and a complicated system that stopped running three months ago is worse than a plugin that works.

The most common backup failure remains the backup that was never tested, which no amount of architecture addresses.

Keep copies offsite, keep several weeks of versions, get one copy out of reach, and test that you can restore it.

What to do

1. Find where the copies are and reach them yourself.
2. Check how far back they go.
3. Extend retention to months, not days.
4. Check whether the credentials can delete.
5. Make one copy the server cannot reach.
6. Include email and photographs.
7. Open one and confirm it is not empty.

Step five is the one that distinguishes a backup arrangement from a recovery arrangement, since everything reachable from the server shares the fate of the server.

Whether they work at all is covered in backups nobody has tested.

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.