Plenty of ransomware victims had backups. That is the uncomfortable part of the story. The files existed, the drives were connected, the jobs reported success — and the restore still failed, because the attacker encrypted the backup server first or because the only surviving copy was nine months old and nobody had ever opened it. What separates a rough week from an unrecoverable one is usually a single question: how many of your copies can an intruder reach with the credentials they already hold?
The 3-2-1 Rule, and Why It Endured
The classic rule is easy to remember: keep three copies of your data, on two different types of media, with one copy offsite. In practice that looks like a production server, a backup appliance or NAS holding the second copy, and a rotated set of tapes, a cloud bucket, or a disk drive living in another building for the third.
It survived for decades because it is cheap, understandable, and it closes the most common failure modes: a dead disk, a deleted folder, a flooded server room, a stolen laptop. Every backup product supports it, auditors recognise it, and a small team can run it without a dedicated storage engineer.
The rule was written for a world of hardware failures and accidents. It was not written for an attacker who logs in as an administrator, reads your documentation, and spends two weeks quietly mapping your infrastructure before detonating.
Where 3-2-1 Quietly Fails
Look closely at most 3-2-1 setups and the two "media" are not really independent. The NAS joins the same Active Directory domain as production. The cloud gateway syncs using a service account stored on a server the attacker already owns. The backup software's management console is reachable from the same flat network. In that arrangement, you have one copy with three names.
Ransomware crews know this. Backup infrastructure and hypervisor snapshots are typically among the first targets, hit before the encryption stage so that recovery options disappear along with the data. If your backup system can be deleted, wiped, or re-encrypted by the same credentials that run your file shares, it is not a separate copy — it is a second victim.
The other quiet gap is time. 3-2-1 says nothing about how long a clean copy survives. Say an intrusion begins in early March and detonation happens in mid-April. If your retention window is thirty days, every remaining backup may already contain the intruder's footholds, scheduled tasks, or tampered data. You restore a clean-looking system and reintroduce the problem.
What the Extra Digits Actually Change
The fourth digit: one immutable or offline copy
This is the copy the attacker cannot touch, even with domain admin rights. Immutable storage — object lock, WORM-capable repositories, append-only backup targets — enforces a retention period in the storage layer itself. Deleting or altering that data is refused by the platform, not by a permission you could revoke or a policy someone could edit.
Offline storage is the more literal version: tape on a shelf, a USB drive powered down in a safe, a rotating disk set that spends most of its life disconnected. No network path, no credentials, nothing to exploit. Some teams also keep a cloud copy in an account with no standing connection to production, so there is no key sitting on a server waiting to be found.
The fifth digit: zero errors, proven
The final zero means zero unverified restores. Not "the backup job finished with warnings" — that is a log line, not proof. It means someone actually recovered a system, booted it, checked that the application started, confirmed the database was consistent, and wrote down how long it took.
A backup that has never been restored is a hypothesis, not a copy.
Immutable, Offline, and Air-Gapped Are Not Synonyms
- Immutable: data cannot be modified or deleted during a set retention window. Fast to restore, automated, but still online — and therefore still reachable by anyone who can send it instructions. Compromise the management layer and you may be able to shorten retention or disable the policy.
- Offline: the media is disconnected when not in use. Strong protection, slower recovery, and it requires someone to plug the drive in or load the tape.
- Air-gapped: no network path exists between the backup environment and production, and administration happens through a separate, isolated path. The strongest option and the most operationally demanding — patches, credentials, and monitoring must all be handled differently.
Most organisations end up with a mix: fast immutable copies for everyday restores, offline copies for the worst case, and a documented process for both.
Recovery Testing Is Where the Zero Is Earned
- Pick a system that would genuinely hurt to lose — your finance database, your file server, your domain controller.
- Restore it from the oldest copy you would actually rely on in a real incident, not the freshest one.
- Time the whole process, from deciding to restore to a working service. Compare that against the downtime your business can survive.
- Verify at the application layer: log in, open records, run a report, check for gaps in the data.
- Scan the restored system before it touches production. A clean backup from an infected window can still carry the intruder's tools.
- Write down what broke, and fix that. Then repeat on a schedule, and once a year run an exercise where the person who built the backups is not the person doing the restore.
Testing tends to surface the same shortfalls: credentials nobody recorded, encryption keys stored on the server that died, restore speeds measured in days rather than hours.
Which Rule Should You Follow?
Treat 3-2-1 as the floor and 3-2-1-1-0 as the target. A two-person business with a laptop and a cloud drive is already doing well to have three copies; the sensible upgrade is one immutable cloud repository rather than a tape library. A mid-sized company with customer data, payroll, and an ERP system should assume an attacker will reach anything with a password and plan accordingly.
Cost is real. Immutable storage carries a premium, tape involves handling and rotation, and air gaps cost staff time. Decide what data truly cannot be recreated, protect that first, and be honest about the rest. If you operate in a regulated sector or have contractual retention obligations, get advice from a qualified professional before finalising your retention windows.
Start Here This Week
List every copy of your data and note which credentials can delete it. Find the one share or service account that turns three copies into one, and break that link. Add a single immutable copy of your most important dataset and confirm the retention lock actually refuses deletion. Put one restore test on the calendar for next month. Finally, decide who is allowed to shorten retention or wipe a repository — and make sure no single person can do it alone.
The rule you choose matters less than whether it survives contact with an attacker who has your admin password and a fortnight of patience.
Photo: wige / Pixabay
