“We have backups.” It's the phrase everyone repeats, and it is exactly where modern ransomware waits for you.

Because serious ransomware no longer just encrypts your data. Before it strikes, it hunts your backups and destroys them, with the same admin rights it just stole. The day you want to restore, there is nothing left to restore.

So the real question is not “do I have backups?”. It is: what survives an attacker who already has the keys? Here are the four layers I built so there is always an answer, and how I tested them.

The threat model: assume the attacker is already admin

The 3-2-1 rule (three copies, two media, one offsite) is a floor, not a ceiling. It protects against disk failure, fire, human error. It does not protect against an attacker who has taken over your domain and can see all three copies from the same account.

So my starting assumption is the worst one: the attacker is already an administrator, has the backup credentials, is on the network. What holds? Each layer answers a case where the previous one failed.

ransomware (admin compromised) ✗ 1 - backup account with no delete rights (append-only) 2 - AES-256-GCM encryption at the source (key off-server) 3 - immutable ZFS snapshots, outside the backup API 4 - offline copy (unplugged, locked retention) stolen account exfiltration compromised server all online wiped ✓ backups intact
Defense in depth: each layer assumes the previous one gave way. Stolen account, exfiltration, compromised server, all online copies wiped: there is always a layer that holds.

Layer 1: a backup account that cannot delete

The backup job runs with an account that can write and read backups, but has no delete or prune rights. Append-only. In practice, even if the attacker steals the backup account's credentials, it cannot erase the backups through the API: the command is refused. The trap to avoid: the “obvious” backup role often includes the prune right. You want the minimal role, not the convenient one.

Layer 2: encryption at the source

Backups are encrypted before they leave the machine, with AES-256-GCM, using a key that lives on the source (and in a vault), never on the backup server. Two benefits: if the backup server is compromised, the attacker only gets unreadable blocks; and against double extortion (“we encrypt, and we threaten to leak your data”), there is nothing to leak.

Layer 3: immutable snapshots, outside the backup software

Suppose the attacker does not just steal an account, but compromises the backup server itself and wipes everything through the API. One thing remains beyond its control: a daily snapshot of the storage, taken at the filesystem layer, outside the backup software. The backup API simply has no command to delete it. Immutable, time-based, invisible to the application.

Layer 4: an offline copy

The last line is the simplest and the oldest: a copy that is not plugged in. A removable medium synced once a week, then disconnected, with a locked retention. Ransomware does not encrypt what it cannot see on the network, and does not erase what is not plugged in. It is slow, it is manual, it is unkillable.

3-2-1 alone admin stolen ✗ ✗ ✗ 1 account reaches all 3 copies = 3 deletable copies Hardened admin stolen ✗ ✓ ✓offline immutable + offline survive online snapshot
The difference is not the number of copies, it is which ones an attacker can reach. With plain 3-2-1, a single account can delete everything. Hardened, the immutable and the offline copies survive.

The test: a backup you never restored is a hope, not a backup

Everything above is worthless if you have not tested it. So I played the attack. I tried to erase backups with the backup account: refused. I restored a whole machine from an immutable snapshot: OK. I checked that the offline copy held its retention. And an automated verification runs every week to catch silent corruption.

A backup you have never restored is not a backup. It is a prayer.

The traps (that nobody documents)

As always, the devil is in the details:

  • The “convenient” backup role that includes prune. You think you are limiting the account, you leave it enough to erase everything.
  • The offline medium that crashes the server. A USB disk crashed the kernel on every connection, until I blacklisted the right module. An offline copy is useless if it takes the server down.
  • Notifications. A backup that fails silently is worse than no backup, because you believe you are covered. Every failure must alert.
  • The overzealous firewall. The backup server's brute-force protection started banning the internal proxy, cutting access for everyone. Secure it, yes, but without locking yourself out.

The takeaway

Four layers, and one simple rule behind each: it assumes the previous one failed. The no-delete account falls? Encryption protects the data. The whole server falls? The immutable snapshots hold. All the online copies fall? The offline copy remains.

And it all runs on open source: a free backup server, ZFS, versioned scripts, monitored and documented. A small team can reach a level of resilience usually associated with six-figure solutions. You do not need a big budget, you need a good threat model.

Ransomware does not ask whether you have backups. It asks whether you can still read them after it has been through. These four layers are my answer.