What makes a backup a backup

· · Security

You have backups. Somebody set them up, they have been running for years, and the light is green. Maybe it is a second drive in the server. Maybe everything important lives in a synced folder that copies itself to the cloud the moment anyone saves. Either way, the data exists in more than one place, so the box is ticked.

It might be. The trouble is that "a copy of the data exists" and "a backup exists" are different claims, and most inherited setups only support the first one. The difference does not show up during a hardware failure, which is the scenario everyone has in mind. It shows up during the scenario nobody designs for: something deletes or encrypts your files on purpose, and your second copy faithfully does the same thing a few seconds later.

This is a design question rather than a discipline question. Testing whether your backups restore is essential, and we have written about running restore drills separately. This filing is about the thing you test: whether the architecture was ever capable of saving you.

The two copies that are not backups

A mirrored disk is redundancy, not a backup. RAID, the arrangement where two or more drives hold the same data so the system survives one of them dying, protects against exactly one failure mode: a drive breaking. It does nothing about anything else, because everything else gets mirrored too. Delete a folder and it vanishes from both drives instantly. Ransomware encrypts both drives at the same speed. A mirror is a useful availability feature and it belongs in your server, but counting it as your backup means you have no backup.

A sync folder is a copy, not a backup. File sync services do their job very well, and their job is to make every copy identical as fast as possible. That is the opposite of what a backup does. When a file is deleted, sync propagates the deletion. When ransomware rewrites 40,000 files, sync uploads 40,000 encrypted files over the good ones and calls it a successful day's work. Most services keep version history, which is a genuine mitigation, but it is usually short, often limited per file, and painful to unwind at scale. Recovering one file someone overwrote on Tuesday, fine. Rolling an entire estate back to Monday morning through a web interface, considerably less fine.

The common thread is that both designs are connected and synchronous. Anything with write access to the original has write access to the copy. An attacker who reaches your file server has, by design, already reached your second copy.

The four properties that make it a backup

Separation. The backup must be reachable from somewhere your production systems are not. In practice that means different credentials from your normal domain admin account, a management interface that is not exposed to the general network, and ideally a copy that is physically or logically disconnected. The National Cyber Security Centre is direct about why: in the early stages of a destructive attack, the attacker goes looking for the backups first, specifically to make paying the ransom your best option. Shared credentials are how they get there. The popular 3-2-1 rule (three copies, on two different types of media, with one held offsite) is a good floor, but it can be satisfied entirely by connected copies, which is why NCSC keeps pushing offline copies on top of it.

Immutability. Immutable means written once and then impossible to change or delete for a fixed period, even by an administrator, even by someone holding every password you own. Cloud object storage sells this as object lock or a retention policy, backup appliances as hardened or locked repositories. This is the single most valuable property in the list, because it is the only one that still holds when the attacker has full control of your network. Set the retention window longer than you would notice a problem: 30 days is a common floor, and if your monitoring is thin, longer.

Versioning with enough depth. One copy of last night is not enough, because the damage you most need to undo is rarely discovered the same day. Corruption, a bad migration, and slow-burn ransomware that encrypts quietly for a fortnight all share a shape: by the time anyone notices, the only surviving copy is a copy of the broken state. You need a ladder of restore points going back far enough to land on a clean one. Daily for a month and monthly for a year is a reasonable shape for a small business.

An honest recovery point objective. Your recovery point objective is simply how much work you are willing to lose, measured in time. If backups run at 2am, your recovery point objective is up to 24 hours: a failure at 5pm costs a full working day of orders, invoices, and case notes. That may be completely acceptable for a document store and completely unacceptable for the database your business bills from. The point is to decide it per system, on purpose, and tell whoever carries the consequences. Most of the anger after an incident comes from a number nobody chose and nobody mentioned.

What to check

  • For each system that matters, ask what would happen if someone deleted everything on it deliberately. If the answer relies on RAID or a sync folder, you have redundancy, not a backup.
  • Confirm at least one copy is immutable or offline, and find out the retention period in days. If nobody knows the number, that is the finding.
  • Write down the real recovery point objective per system, based on when backups actually run, not when the policy says they run. Share the numbers with the people who would live with them.
  • Check the backup system uses separate credentials from your day-to-day administrator accounts, with multi-factor authentication on any request to delete or shorten retention.
  • Check you get an alert when a job fails, when retention is reduced, and when a large deletion is attempted. Silence is not the same as success.

How Steelwise can help

Working out whether a backup setup would actually survive a deliberate attack, rather than a dead disk, is a short and well-defined piece of security advisory work. Get in touch if you would like a straight answer on yours.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.