Blog · By Nimrics · 7 Sept 2026 · 5 min read
Backups That Survive Ransomware: The 3-2-1-1-0 Rule, Explained
Most companies that pay a ransom had backups. They just had the wrong kind. What 3-2-1-1-0 means in practice, why the extra "1" and "0" matter, and a weekend plan for a small business.
Ask a business owner whether they have backups and almost everyone says yes. Ask when they last restored a file from one and the room goes quiet. That gap — between having backups and being able to recover — is where ransomware makes its money.
Ransomware is simple. Malicious software encrypts your files and the criminals sell you the key. The defence is equally simple in principle: keep a copy of your data that they cannot reach, and know how to put it back. The reason companies still pay is that the copy they had was reachable, or was never tested. This post is about fixing both.
The old rule and why it was not enough
For years the standard advice was 3-2-1: three copies of your data, on two different types of media, with one copy off-site. It is still good advice. It protects you against a dead disk, a stolen laptop, a fire in the office.
It does not, on its own, protect you against ransomware, because modern ransomware is patient. It sits on the network for days or weeks, finds every drive and share it can reach — including the network storage where the "backup" lives and the cloud folder that syncs it — and encrypts everything at once. If your backup is a folder that a logged-in computer can write to, it is not a backup from ransomware's point of view; it is another target.
Two additions close that gap.
3-2-1-1-0
3 copies — production plus two backups.
2 media — for example, a local disk and a cloud service. Different technologies fail differently.
1 off-site — a fire, flood or burglary must not take the backup with it. For most small businesses today, "off-site" means a cloud backup service, and that is fine.
1 offline or immutable — this is the ransomware clause. One copy must be either physically disconnected (an external drive that is unplugged after each backup; a tape in a drawer) or immutable: stored in a way that cannot be changed or deleted for a set period, even by an administrator. Most serious cloud storage offers this — object lock, retention locks, "vault" tiers. Immutability is what turns a backup from a copy the attacker can also encrypt into a copy the attacker cannot touch.
0 errors — the backup is verified. Not "the job said success", but a real restore, done on a schedule, that produced usable files. A backup you have never restored is a hypothesis.
What this looks like for a small business
Here is a realistic setup for a company of five to fifty people that does not have a full-time IT department.
Your data is in three places. Work out where it actually lives: laptops, a shared drive or cloud storage (Google Drive, OneDrive, Dropbox), and your line-of-business systems (accounting, CRM, your own product's database). Each needs its own answer.
Laptops. Turn on the platform's built-in backup — Time Machine, Windows Backup, or the sync client of your cloud storage — so that nothing important lives only on one machine. This is the "convenience" copy; it is not the ransomware copy.
Shared files. Cloud storage services keep file version history, which recovers from a small ransomware event, but retention windows are short and mass-deletion by a compromised account is a real risk. Add a proper backup of the cloud storage to a separate provider or to a backup service that supports immutability. This is where most small businesses have a gap.
Databases and systems. Automated daily snapshots, kept for at least thirty days, copied to a second region or provider with immutability enabled. If you run your own product, this is non-negotiable; customer data you cannot restore is a company you cannot keep.
The offline copy. Once a month, back up the critical set to an external drive and physically disconnect it. Label it with the date. Keep two and alternate. It sounds primitive; it has saved more companies than any product I could name.
The restore test
Put a recurring event in the calendar — quarterly is a good rhythm — with one job: restore something.
- Pick a file from three months ago and get it back.
- Restore the database snapshot to a scratch server and check the application starts.
- Time it. If your business would be down for a day, that is your recovery time objective and you should know it before an incident rather than discover it during one.
- Write down what went wrong. Something always does the first time, and that is the entire point of testing.
Questions to ask before an incident, not during
- How much data would we lose? If backups run nightly, up to a day. Is that acceptable for orders, invoices, customer records? If not, back up more often.
- Who can delete backups? Fewer people than can create them. The backup administrator account should have its own strong credential and two-factor authentication, and ideally deletion should require a delay or a second person. Attackers delete backups before they encrypt.
- Where are the keys? If your backups are encrypted — they should be — the encryption key must be stored somewhere that survives the same disaster. A key that only exists on the server you are trying to restore is a locked box with the key inside it.
- What is the plan on the day? Who calls whom, which systems come back first, and who talks to customers. Write a one-page version. Print it; the wiki may be encrypted too.
On paying
Law enforcement agencies in most countries, including CISA and the FBI in the US and the NCSC in the UK, advise against paying: it funds the next attack, it does not guarantee a working decryptor, and it marks you as a company that pays. Companies pay because they have no other way back. The backup strategy above is the other way back. It costs a fraction of a single ransom and a few hours a quarter.
The rule fits on a sticky note: three copies, two media, one off-site, one they can't touch, zero unverified. If your current setup misses the last two, this weekend is a good time to fix it.