Backups that survive ransomware: the 3-2-1 rule in practice

The uncomfortable fact about modern ransomware is that it does not race you to encrypt your files. It takes its time, and it looks for your backups first. The attacker knows that a business with a good, reachable backup will simply restore and refuse to pay — so before triggering the encryption, they hunt down the NAS in the closet, the always-connected USB drive, and the network share helpfully named BACKUP, and they destroy those. By the time you notice anything is wrong, the copy you were counting on is already gone.

This is why “we have backups” is not the same as “we can survive ransomware.” Surviving it is an architecture, and the classic name for that architecture is the 3-2-1 rule. This piece is about what 3-2-1 means, why it now needs two more digits, and how to run it in a way that actually holds up under attack. It is a companion to our post on testing that your backups restore — that one is about proving a backup works; this one is about designing backups an attacker cannot reach.

The 3-2-1 rule, stated plainly

Three numbers, one sentence:

• 3 copies of your data — the live copy plus two backups.
• 2 different kinds of storage — so a single technology or device failure cannot take out more than one copy at once.
• 1 copy offsite — so a fire, flood, theft, or a compromise of your premises does not destroy everything in one event.

The logic is that no single failure should be able to take out all your copies. A dead drive, a burned building, a stolen laptop — each of these can destroy one copy, and 3-2-1 makes sure it never destroys all of them. For decades this was enough, because the threat model was hardware failure and physical disaster.

Ransomware broke that model, because ransomware is not a single failure. It is an intelligent adversary that moves across your network looking for every copy it can reach. Three copies do not help if all three are online and reachable from the same network the attacker is already inside.

Why 3-2-1 became 3-2-1-1-0

The updated version adds two digits that speak directly to the ransomware threat:

• 1 copy offline or immutable — at least one copy the attacker cannot alter or delete even after they have full run of your network.
• 0 errors on a tested restore — because a copy that survives but will not restore is not a backup, it is a false sense of security.

Those two additions are the difference between a backup strategy from before ransomware and one built for it. The offline-or-immutable copy is your insurance against the attacker; the zero-error restore test is your insurance against yourself. Take them one at a time.

The offline or immutable copy

This is the copy that saves the business, so it is worth understanding the ways to achieve it.

Offline, or air-gapped. A copy that is physically disconnected from the network except during the backup window. A drive that is rotated and stored elsewhere, or media that is written and then removed. If it is not connected, an attacker on your network cannot touch it. The tradeoff is that it depends on someone actually doing the rotation, which makes it a process risk as much as a technical one.

Immutable. A copy written in a way that cannot be changed or deleted for a set retention period, even by an administrator, even by someone holding valid credentials. Object storage with an object-lock or write-once-read-many mode is the common form. The point is that “delete this backup” is simply not an operation the system will accept until the retention window expires — so an attacker with your admin password still cannot erase it. Cloud object storage with a lock is often the most practical way for a small business to get immutability without managing tapes.

Both, ideally. Offline protects against network reach; immutable protects against credential compromise. A copy that is offsite and immutable covers the widest range of disasters at once. The right mix depends on your setup, and it is one of the things we work through when we design a business’s infrastructure for recoverability rather than just for storage.

The test to apply to any backup copy is a single question: if an attacker had full administrator access to my network right now, could they destroy this copy? If the answer is yes, it is not the copy that survives ransomware. You need at least one where the answer is no.

Why the online backup is the one they delete first

It is worth being blunt about the failure mode, because it catches careful people. The backup most businesses trust most — the automated one, running nightly to a device on the network, monitored and green in the dashboard — is precisely the one an attacker finds and destroys, because it is reachable. Its convenience is its vulnerability. Everything that makes a backup easy to manage from your network also makes it easy for an intruder on that network to reach.

This does not mean abandon the convenient backup. It means do not let it be your only one. Keep the fast, online copy for the everyday case — the deleted file, the failed drive, the ordinary recovery — and keep a separate offline or immutable copy for the day the everyday copy is compromised. They protect against different threats and you want both.

Retention: outlasting the attacker’s patience

Ransomware does not always trigger the moment it gets in. Attackers often sit in a network for weeks, quietly ensuring their access is baked into your backups before they strike, so that restoring simply reinfects you. Retention is your defence against this.

• Keep enough history. If you only retain a week of backups and the attacker was in your systems for a month, every copy you hold is compromised. Retention measured in months, with periodic points kept longer, gives you a clean restore point from before the intrusion.
• Use versioned or point-in-time copies, not a single rolling backup that overwrites itself. A backup that only holds “last night” holds last night’s compromise.
• Match retention to immutability. An immutable copy is only protected for its retention window — set that window long enough to cover a realistic dwell time, not just a few days.

Retention is the quiet part of the strategy that turns “we have a backup” into “we have a backup from before this started.”

Testing the restore — the zero

The final digit is the one people skip, and it is the one that decides whether any of the above mattered. A backup you have never restored is a hypothesis. Ransomware recovery is a bad time to discover the immutable copy has been quietly failing for three months, or that the restore takes a week you do not have.

We wrote the full restore-testing method — pick a real target, restore to a separate location, open what came back, time it, document it — in our backups restore post, and it applies here without change. The one addition for ransomware specifically: test restoring from the offline or immutable copy, not just the convenient online one, because the offline copy is the one you will actually reach for on the worst day. A restore path you have never exercised is not a plan.

Making it somebody’s job

Every part of this — the offline rotation, the immutability settings, the retention windows, the quarterly restore test from the protected copy — is a process, and processes decay when they are nobody’s responsibility. The most common reason a business with a sensible backup design still loses to ransomware is not a flaw in the design; it is that the offline copy stopped being refreshed six months ago and nobody was watching. Keeping devices patched and backups verified on a schedule, with a named owner and a report you actually see, is the substance of what a managed practice like our device management provides.

If you are not certain whether your current backups would survive an attacker with full access to your network, that uncertainty is the finding. Send us two paragraphs about how your data is backed up today — online, offline, immutable, and how far back — and we will reply in writing within one business day.