The 3-2-1 rule and immutable backups: an architecture against ransomware

The right question is not “do you have backups?”: everyone says yes. It is “when did you last restore, and what stops an attacker who controls your servers from destroying your backups along with everything else?”. The vast majority of SMEs answer both questions badly. Here is the 3-2-1 rule, what needs adding to it in 2026, and the architecture we run.

The 3-2-1 rule, and why it is no longer enough #

The rule is simple and its principle has not aged a day: 3 copies of your data (production included), on 2 different media or systems, of which 1 is offsite. It protects against hardware failure, human error and fire. But it was formulated before ransomware became an industry, and ransomware has changed one fundamental thing: your backups are now the first target, not the last line of defence.

A competent ransomware operator does not encrypt your servers on the day they get in. They explore, collect credentials, locate the backups, then destroy or encrypt them first. If your production server knows the password of the backup NAS, your three copies are really one. Hence the two modern additions, sometimes summed up as “3-2-1-1-0”: 1 immutable or offline copy, and 0 restore errors, meaning restores that are actually tested.

Immutability: a copy nobody can modify, not even you #

An immutable backup is a copy that no compromised credential can alter during its retention period. In practice, it is built on two architectural principles:

• The backup server does not trust the machines it backs up. Each machine drops off its backups with write-only rights (append-only): it can add, never delete or modify. An attacker who controls production therefore cannot destroy the history: deletions and retention are managed on the backup server side, with different credentials.
• *The offsite copy is made in pull mode, not push. It is the remote site that comes to pull* the backups, with its own read access. The production chain holds no credentials to the offsite copy: it does not even know it exists. Compromising production gives no path to the last line of defence.

The test is simple: from a compromised production server, with all its secrets, can the backups be destroyed? If the answer is not a demonstrable “no”, you do not have backups: you have temporary copies.

Our architecture in production #

Here is how these principles take shape on the infrastructure we run for our clients, with Proxmox Backup Server, whose deduplication and retention we have already covered in detail:

• Daily backups of every machine to a dedicated backup server, outside the production cluster, in append-only mode: production writes, it deletes nothing.
• A sealed space per client (namespaces): each tenant has its own access, nobody sees anyone else’s data, and the blast radius of a compromised credential stays limited.
• Deduplication measured at 7.4× across our fleet: keeping weeks of history costs a fraction of the raw volume, so long retention stops being a financial trade-off.
• Offsite mirror in pull mode, on a geographically separate site, with its own read-only credentials and independent retention.
• Client-side encryption for the backups we host for third parties: we store encrypted blocks whose key we do not hold.

An untested backup does not exist #

The “0” in 3-2-1-1-0 is the most neglected. Backups fail silently: a job that has been crashing for weeks, a full volume, a database exported hot and left inconsistent. The only proof of a backup is a real restore: a complete machine brought back up on a blank host, the database replayed, the application started and checked. We do it periodically on our own infrastructure, and the first test always has something to teach: ours revealed procedural details that no theoretical documentation would have caught.

Audit your backups in five questions #

1. From a compromised production server, can the backups be deleted or encrypted? (append-only, separate credentials)
2. Is the offsite copy reached by push from production, or pulled from the remote site?
3. When was the last successful full restore, and who witnessed it?
4. Who is alerted when a backup job fails, and has the alert been tested by deliberately breaking a job?
5. Does your retention cover ransomware discovered late? (an attacker can wait weeks before encrypting)

This architecture is included in our sovereign hosting and our managed services: daily backups, an immutable copy, offsite storage and restore tests. If you want to run the five questions above against your own setup, we can do it together.