IT consulting · Integration · Training   for companies and public administrationsinfo@grub-it.com · (+237) 650 46 00 15
Article · 7 November 2026 · 5 min read

3-2-1 backup: why it is no longer enough against ransomware

Ransomware goes after your backups first. Immutable copy, offline copy, separate accounts and restore tests: how to evolve the 3-2-1 rule into real protection.

Every administrator knows the 3-2-1 rule: three copies of the data, on two different media, one of them off site. It protects well against a disk failure, a fire in the server room or human error. Against ransomware, it is no longer enough.

Attackers go after the backups first

Modern ransomware does not just encrypt files. Attackers often spend several days inside the network, harvest administrator credentials, then delete or encrypt the backups before launching the attack. If your backup server is joined to the same directory as your servers, and its repositories can be reached with the same accounts, all three copies can disappear within minutes.

Moving to 3-2-1-1-0

The rule has therefore evolved. On top of three copies, two media and one off-site copy, add:

  • 1 immutable or offline copy: a copy that nobody can change or delete during its retention period, not even an administrator. For example object storage with Object Lock, or media that are physically disconnected (rotating external disks, tape).
  • 0 errors on restore: every backup is verified, and restores are tested regularly.

Isolating backup from the rest of the information system

Immutability is useless if the attacker can take over the backup console. A few simple measures greatly reduce the risk:

  • Dedicated accounts for backup, used for nothing else, with two-factor authentication.
  • A backup server outside the main directory (Active Directory or LDAP), on a separate network, reachable only from administration workstations.
  • Limited rights for the servers being backed up: they can write new backups, not delete old ones.
  • Alerts on mass deletions and on failed backup jobs.

Define RPO and RTO, then check them

Two figures should drive your strategy. The RPO (maximum acceptable data loss) sets how often you back up: a billing database is not backed up like a file share. The RTO (maximum acceptable downtime) sets how you restore: restoring ten terabytes from a remote site can take days over a slow link.

These objectives are only worth something if they are tested. Plan at least one full restore exercise per quarter on a real application, time it, and compare the result with the RTO promised to the business.

A checklist to get started

  • Do you have at least one copy that an administrator cannot delete?
  • Does the backup server use accounts separate from those of the domain?
  • When did you last restore a complete application?
  • Are the RPO and RTO of your critical applications written down and approved by the business?
  • Who is alerted if a backup fails three nights in a row?

If any of these questions has no answer, that is where to start. Backup is the last line of defence: it deserves the same attention as the firewall.

Share this article On WhatsApp On LinkedIn