Backups: the 3-2-1 strategy in practice

In incident response there is a moment of truth that splits companies into two groups: “we’re restoring from backup” and “we have to negotiate with criminals”. Which group you land in is decided by work done months earlier — the backup architecture and whether anyone ever rehearsed a restore. This article walks through the whole picture: from the classic 3-2-1 rule, through ransomware-proof copies, to a recovery plan that doesn’t exist only on paper.

Why backup is the control of last resort

Backups protect against a wider class of events than any other control: ransomware, human error (accidental deletion, overwrites), hardware failure, a bad update, sabotage, fire or a flooded server room. That’s exactly why attackers prioritise them: modern ransomware groups find and destroy the backups first, and only then encrypt production. Your backup architecture must therefore assume an adversary with domain administrator privileges — because on the day of the attack, they’ll probably have them.

The 3-2-1 rule (and its modern extension)

The classic formula still holds:

• 3 copies of the data — production plus two backups,
• 2 different media/technologies — e.g. array + cloud, disk + tape,
• 1 copy off-site — another site, the cloud, physically separated media.

The modern extension, 3-2-1-1-0, adds two requirements that make the difference in the ransomware era:

• 1 offline or immutable copy — one that cannot be encrypted or deleted even from an admin account: a tape in a safe, storage with object lock (WORM), immutable snapshots,
• 0 verification errors — copies are automatically verified and restores are regularly rehearsed.

The most common sin we find in audits: all “three copies” are reachable from the same Windows domain, with the same credentials. Formally 3-2-1; from an attacker’s point of view — one copy.

Immutability and separation: how to do it technically

Object lock in the cloud. A backup repository in S3/Azure/GCS with object lock in compliance mode: for a set period (e.g. 30 days) nobody can delete the copies — not an attacker, not an administrator, not the provider at your request. It’s the cheapest route to true immutability today.

A separate identity. The backup infrastructure (server, repository, console) lives outside the production domain: separate accounts with their own MFA, separate access workstations, no trust with AD. Taking over the domain must not mean taking over the backups — the same thinking as in Active Directory hardening.

Air gap where possible. Physically disconnected tapes or disks still make sense for critical data — a medium in a safe is immune to every network attack by definition.

Encrypt the backups. Copies contain everything, so they are themselves a theft target. Encrypt them and keep the keys outside the backup system.

What to back up (the checklist people forget)

Servers and databases are obvious. What we regularly find missing:

• SaaS data — M365/Google Workspace, CRM, online accounting. The provider ensures service availability, not recovery of your data after deletion or a malicious action — we covered this for M365.
• Configurations — network devices, firewalls, infrastructure-as-code, the backup system’s own configuration.
• Secrets and keys — the password vault, encryption keys, tokens; rebuilding an environment without them can be impossible.
• Key people’s workstations — if data lives locally (design, finance) and not only on servers.
• Restore dependencies — documentation, licences, installation media. A 3 a.m. restore is a bad time to hunt for a licence key.

For each category set the RPO (how much data you can lose — i.e. backup frequency) and RTO (how fast you must be back — i.e. restore technology). An online shop may need a 15-minute RPO for the orders database and 24 hours for files — these are business decisions, not server-room ones.

Testing: an untested backup doesn’t exist

Three levels of verification, from automated to a full exercise:

1. Automated verification — daily checksum and mount checks; an alert on every failed job.
2. Sample restore test — monthly restore of a chosen system/database to a test environment with the time measured; rotating, so everything critical is covered within a year.
3. A scenario exercise — once a year, a full simulation: “ransomware encrypted the domain, you have the latest backups — get up”. The RTO measured in that exercise is the only true answer to the board’s question “how long will we be down”.

Document the test results — that evidence is required by NIS2, by insurers and by common sense.

Restoring after ransomware: two traps

After an attack the backups are treasure, but restoring has catches. First, don’t restore the infected state: attackers often sit in the network for weeks, so a three-day-old copy may contain their backdoors. You need analysis of the entry point and restoration into a clean or isolated environment, with credentials rotated. Second, preserve the evidence: overwriting everything “to get up quickly” can destroy the material needed to establish the scope of a data breach — and that has legal consequences.

Frequently asked questions (FAQ)

Is cloud sync (OneDrive, Dropbox) a backup? No. Sync replicates the damage too: an encrypted or deleted file “syncs” everywhere immediately. Versioning helps with single files but doesn’t replace a copy independent of the user’s account — a hijacked account can wipe the data, the versions and the recycle bin.

How long should we keep backups? In tiers: dailies for 2–4 weeks, weeklies for 2–3 months, monthlies for a year, and selected yearlies per legal requirements (accounting!). Long retention also defends against late-detected attacks: if the intrusion has been running for a month, a six-week-old copy can be priceless.

How much should a company spend on backup? The reference point is the cost of downtime: calculate the cost of one day of unavailability (lost sales + staff time + contractual penalties) and set it against the backup budget. It usually turns out that an immutable cloud repository and licences cost a fraction of a single day of downtime.

We have “backup” in RAID/replication. Is that enough? RAID and replication protect against hardware failure, not against deletion, ransomware or mistakes — a replica will faithfully copy every bit of damage. They are availability mechanisms, not backups; you need both.

Who should have access to the backup system? As few people as possible, with separate accounts and MFA, with all operations logged and an alert on deleting copies or changing retention. Consider a four-eyes rule for destructive operations. In our security audit we check exactly these paths — because an attacker will too.

Summary

A good backup is architecture (3-2-1-1-0, immutability, a separate identity), conscious business decisions (RPO/RTO per system) and regularly rehearsed restores. That set turns the worst-case scenario — ransomware with a ransom demand — into a measurable outage without paying criminals. Want to know whether your backups would survive an attacker holding domain admin? We’ll check as part of an audit — including a restore test. Write to us.