Backups That Survive Ransomware: Why Most Organisations Find Out Too Late

Every organisation hit by ransomware had backups. That is not the exception, it is the norm. What they did not have was backups the attacker could not reach, or backups anyone had successfully restored from.

Attackers understand that backups are the only thing standing between them and a payment, so destroying them is a deliberate early step — often days before any encryption begins.

What the attack actually does to your backups

The sequence is consistent. Gain access, escalate to an administrative account, locate the backup infrastructure, delete or encrypt it, then encrypt production. Encryption is the last step because it is the one that triggers the alarm.

This means any backup reachable with administrative credentials from the production domain should be assumed to be gone. Network shares holding backup files, backup servers joined to the same domain, cloud storage whose keys are on a compromised server — all of them fail at the same moment as everything else.

The rule, updated

The familiar guidance is three copies, on two media types, with one off-site. Two additions matter now:

• One copy immutable or offline. Write-once storage, object lock, or genuinely disconnected media. Something that cannot be deleted even by a valid administrator.
• Zero errors on restore testing. A backup job reporting success is a statement about the job, not about the data.

Immutability is the control that matters

Immutable storage accepts writes and refuses modification or deletion for a defined retention period. Even with full administrative credentials, the data cannot be removed before that period expires.

Two details decide whether it works. The retention period must exceed your realistic detection time — attackers frequently sit in a network for weeks, so a seven-day lock may expire before anyone notices. And the account that configures the policy must not be the same account that administers production.

Isolate the credentials, not just the storage

A backup server joined to the same directory as everything else is protected by exactly the same credentials as everything else. Separate the identities: backup administration should use accounts that do not exist in the production domain, with their own multi-factor authentication.

The test to apply: if the domain administrator account were fully compromised right now, could it delete the backups? If yes, the backups are inside the blast radius.

Restore testing is the part that gets skipped

Backup success rates are reported in every monthly pack. Restore success rates almost never are, and they are the only number that matters.

Test by actually restoring, to a clean environment, and verifying the data opens and the application starts. Common discoveries: the database restores but the encryption key was only on the original server; the application server restores but nobody documented the configuration; the restore works but takes eleven days at your available bandwidth, which changes the entire incident plan.

That last point is why recovery time matters as much as recovery point. Know how long a full restore genuinely takes, measured rather than estimated.

Keep the backups clean

If an attacker was present for six weeks, backups from that period may contain their persistence mechanisms. Restoring them reinstates the intrusion.

Retain far enough back to find a known-good point, keep a record of when suspicious activity began so you can choose a restore point deliberately, and scan restored systems before reconnecting them.

Write the plan down, off-network

Recovery procedures stored only on the network being recovered are a recurring and avoidable problem. Keep an offline copy of the runbook, the contact list, the licence keys and the credentials needed to begin.

Frequently asked questions