Ransomware Backups That Actually Work: The 3-2-1-1 Rule Explained

Every business we assess has backups. Roughly half have never restored from them, and a

meaningful proportion have backups that a ransomware operator would delete in the first ten minutes

of an attack.

Why ordinary backups fail

Ransomware groups understand that backups are the reason victims do not pay. So the modern playbook

does not start with encryption. It starts with reconnaissance: find the backup server, find the

backup credentials, delete or encrypt the backups, and only then trigger the encryption everyone

notices.

If your backup sits on a network share, on a NAS joined to the domain, or in a cloud account

reachable with the same administrator credentials as everything else, it is inside the blast radius.

It is not protecting you.

3-2-1-1, and why the last digit is the one that matters

• **3** copies of your data — the live copy plus two backups
• **2** different media or storage types, so one failure mode cannot take both
• **1** copy off-site, protecting against fire, flood and theft
• **1** copy offline or immutable, protecting against an attacker with your credentials

The first three digits are the traditional rule and they protect against accident and hardware

failure. The fourth was added because of ransomware, and it is the one that decides whether you pay.

What immutability actually means

An immutable backup cannot be modified or deleted for a defined retention period — not by you, not

by your IT provider, and not by an attacker holding domain administrator credentials. Cloud object

storage implements it as object lock; backup appliances implement it as hardened repositories. The

mechanism differs; the property is the same.

That property is what makes it effective. Every other control can be turned off by someone with

enough privilege. This one cannot, by design.

Separate the credentials

A backup system that authenticates with the same domain administrator account used for everything

else inherits every compromise of that account. Backup infrastructure should use its own accounts,

with their own multi-factor authentication, not joined to the domain it is protecting.

This is the single most commonly missed configuration detail, and it converts an otherwise sound

backup design into a decorative one.

The part everyone skips

A backup you have never restored from is a hypothesis, not a backup.

Schedule real restore tests. Not a "backup completed successfully" email — an actual restore of an

actual server or dataset to somewhere isolated, timed, with the result written down. The first time

you do this, you will find something: a database that will not come back consistent, a dependency

nobody documented, or a restore that takes eleven hours when the business assumed two.

1. Restore a representative server or dataset to an isolated environment
2. Time the full process end to end, including the parts nobody counts
3. Verify the data is actually usable, not merely present
4. Record the result, and compare it against what the business believes
5. Repeat quarterly, and after any significant infrastructure change

The number you are looking for is not "do we have backups". It is "how many working days would we

lose". Most businesses do not know, and the answer is usually longer than the assumption.

Do not forget the cloud

Microsoft 365 retention policies and recycle bins are not a backup. They protect against accidental

deletion for a limited window. They do not protect against a compromised administrator systematically

purging mailboxes, and Microsoft's own service agreement places responsibility for data backup on

the customer. A third-party backup for your cloud tenant is inexpensive and routinely missing.