Why your backup won't stop ransomware — and what the 3-2-1-1-0 rule fixes

Ask most business owners whether they are protected against ransomware and they will say yes, because they have backups. That answer was good enough ten years ago. When Sophos surveyed ransomware victims, 94 percent of the companies that had backups found the attackers had gone after those backups too — deleting them, encrypting them, or quietly corrupting them before the ransom note ever appeared. The rule most businesses still follow is called 3-2-1. The rule that survives a modern attack is 3-2-1-1-0, and its whole point is one immutable backup copy that nobody can delete: not your IT provider, not a disgruntled employee, and not an attacker who has stolen your administrator password.

This article explains why the rule changed, what those two extra digits mean, what it costs a company of 20 to 200 people to put right, and how to find out in a single afternoon whether your own backup would survive. If you would rather have someone check it properly, that is precisely what our backup and disaster recovery service is for.

The rule your IT setup probably follows — and why it stopped working

The 3-2-1 rule is simple and, for decades, it was excellent advice: keep three copies of your data, on two different types of storage, with one of them off-site. It is the reason a burst pipe in the server room or an employee deleting the wrong folder does not end your company.

Notice what those disasters have in common. A flood does not hunt for your backup server. A dying hard disk does not go looking for the credentials to your off-site storage. The 3-2-1 rule was designed to survive accidents, and it does that well. It was never designed to survive an adversary — the difference that has quietly made it obsolete.

Modern ransomware groups are organised and patient. They do not break in and start encrypting the same afternoon; they typically spend weeks inside a network, escalating until they hold administrator rights. The first thing they do with those rights is not encrypt your files. It is find and destroy your backups — the backup server, the network share it writes to, the credentials stored inside the backup software itself. Only once your safety net is shredded do they encrypt production and send the demand. By design, you are left with nothing to restore from and no leverage.

Two comfortable assumptions fail small businesses here. An off-site copy is not safe merely because it is somewhere else: if your backup is reachable from your network, it is reachable by whoever owns your network. And file sync is not backup — OneDrive, SharePoint and Dropbox faithfully replicate whatever happens to a file, so when ransomware encrypts the original, the sync obediently copies the encrypted version everywhere. Knowing which of your defences are real is a core part of any serious cloud security review.

What the 3-2-1-1-0 rule actually means

The 3-2-1-1-0 rule keeps everything that worked about the old rule and adds the two things that stop a deliberate attacker:

• 3 — three copies of your data. The live version you work on daily, plus two backups. One backup is a single point of failure.
• 2 — on two different types of storage. A local disk appliance and cloud object storage, for example. If one class of storage fails or is compromised, the other still stands.
• 1 — one copy off-site. Geographically separate, so a fire or burglary at your office cannot take every copy at once.
• 1 — one copy immutable or air-gapped. The new one. A copy that cannot be altered or deleted, even by someone holding full administrative rights.
• 0 — zero errors on restore. The other new one. Backups are verified and genuinely test-restored, so you know the data comes back rather than hoping it will.

The first three digits protect you against bad luck. The last two protect you against bad people. Almost every small business we assess has the first three in some form and neither of the last two — a fair description of why ransomware remains so profitable.

The extra "1": a copy nobody can delete

Immutable simply means unchangeable. An immutable backup is written once and then locked for a defined retention period. During that window the data cannot be modified, overwritten or deleted by anyone — not the backup administrator, not a support engineer, not someone logged in with your stolen domain administrator account. The storage system itself refuses the delete command. It is the digital equivalent of posting documents into a safe that has no key until a certain date.

That property breaks the ransomware business model. The attacker's plan depends on removing your ability to recover. Against an immutable copy they can hold every credential in your company and still be unable to touch it. You restore, you refuse to pay, and their leverage evaporates. An air gap achieves the same outcome physically: the copy is disconnected from the network entirely once written. This is why the German Federal Office for Information Security (BSI) puts an offline backup — separated from the network after the backup job finishes — near the top of its ransomware recommendations.

Owners tend to assume this is enterprise territory with an enterprise price tag. It is not, and that assumption is now the main thing standing between many companies and real protection. Immutability is a standard feature of cloud object storage — immutable containers in Azure Blob Storage, or object lock elsewhere — and reputable backup products expose it as a checkbox on the storage target. Storing an immutable copy costs tens of euros per terabyte per month, with no tape robot and no vault involved. Switching it on correctly is a half-day job for someone who has done it before, and a routine part of how we run a client's managed cloud environment.

One detail matters more than any other: set the retention lock longer than an attacker's likely dwell time. If your immutable copy is locked for seven days but the intruder has been in your network for three weeks, they simply wait for the lock to expire on every clean copy. Thirty days is a sensible floor; ninety is better when the storage cost is trivial, which it usually is.

The "0": an untested backup is only a rumour

The final digit is the one businesses skip, and the one that turns a backup strategy into an actual recovery. Zero errors means your backups are verified and your restores are tested — that you have watched real data come back, recently, and know how long it took.

The gap is enormous. Research on small and medium businesses consistently finds only around six in ten regularly test whether their backups can be restored. Four in ten companies, then, have no idea whether the thing they are relying on in their worst week works at all. They find out on the day, which is the most expensive possible moment to learn the answer.

A green tick in your backup console does not mean what most owners think. It means the job ran. It does not mean the data inside is complete, uncorrupted or bootable. Backups fail silently in thoroughly ordinary ways: a database was open and got captured mid-write, a new server was never added to the job, the retention policy quietly aged out the copy you need, or the encryption key protecting the backup lives only on the server ransomware just encrypted.

Testing also converts vague reassurance into a number you can plan around. There is a world of difference between "we have backups" and "we restored our main file server last quarter, it took eleven hours, so an incident on Monday means we are trading again by Tuesday afternoon." Only the second lets you decide in advance whether eleven hours is acceptable — and if not, what to change. Test the restore, not the backup job, at least quarterly, and write down the date, the result and the time it took.

What it costs — and what it saves

The average company hit by ransomware in recent years has been a mid-sized business of a couple of hundred employees, and the typical victim has faced roughly three weeks of serious disruption. Not three weeks of inconvenience — three weeks in which orders cannot be processed, invoices cannot be raised, and the phones are answered with an apology.

Make it concrete. Take a 40-person firm turning over six million euros a year: roughly 25,000 euros of revenue on every working day. A comparatively lucky five-day outage costs about 125,000 euros in lost trading alone, before incident response, legal advice, notifying regulators and customers under GDPR, and the contracts that quietly go elsewhere afterwards. Paying the ransom is not the escape hatch it appears to be: the decryption tools criminals supply are frequently slow and partial, and a significant share of companies that pay never recover all their data.

Now price the defence. An immutable off-site copy of a few terabytes costs a few hundred euros a year in storage; configuring it properly is a one-off engagement measured in hours; a quarterly restore test costs half a day of someone's attention. Even generously costed and wrapped into a managed service, a small business is looking at low four figures annually to make the difference between a bad fortnight and an extinction event. Very few line items on a budget have that return, and none are as easy to keep postponing.

What German and EU rules already expect from you

For companies operating in Germany this has stopped being purely a matter of good practice. The BSI's ransomware guidance is explicit that a backup is the single most important preventive measure, that at least one copy must be held offline and disconnected from the network after the backup runs, and that the recovery process must be planned and put through a practical test before a real emergency rather than improvised during one.

NIS2 hardens this. For the roughly 29,000 German companies now in direct scope, backup concepts and documented recovery testing are named obligations, not suggestions. If you are not directly in scope, do not relax too quickly: regulated companies must manage the security of their supply chain, so their questionnaires land on their suppliers' desks. A straightforward "how do you protect and test your backups?" increasingly sits between a smaller company and a contract renewal.

GDPR has quietly required something similar all along. Article 32 obliges you to restore the availability of and access to personal data in a timely manner after an incident. An untested backup does not demonstrate that ability; a documented quarterly restore test with a recorded recovery time does. German retention rules such as the GoBD add their own duty to keep certain records intact and available for years. Making all of this auditable, instead of a matter of assurance, is what our governance and compliance work is for.

A checklist you can run this month

None of this requires a project. Work through these seven points in order and you will know exactly where you stand.

• Count the copies, honestly. Write down every place your data actually exists. Sync services do not count. Most businesses discover they have two, not three.
• Ask the only question that matters. "If an attacker had our domain administrator password right now, could they delete this copy?" If the answer for every copy is yes, you have no protection against ransomware, whatever you spend on backup.
• Turn on immutability for at least one copy. Use object lock or an immutable container on your cloud storage target, with a retention lock of at least 30 days.
• Separate the backup credentials. The account your backup software uses must not be a domain administrator, must not reuse a password from anywhere else, and must have multi-factor authentication. This single change defeats a large share of real attacks.
• Back up Microsoft 365 as well. Microsoft protects its platform, not your content. Under its shared responsibility model, the mail, files, SharePoint sites and Teams data in your tenant are yours to back up, and native retention is not a backup. If you are unsure what your licences cover, our Microsoft 365 team can tell you in an hour.
• Restore something real. Not a test file — a genuine server or file share. Time it. Write the number down. That is your true recovery time, and it is almost always longer than anyone expected.
• Put the next test in the calendar. Quarterly, with the date, result and duration recorded each time. That record is simultaneously your operational safety net and your compliance evidence.

Quick answers

Is OneDrive or SharePoint a backup? No. They are sync and collaboration tools. If a file is encrypted or deleted, that change syncs everywhere. Versioning and the recycle bin help with small accidents and will not save you from an attacker holding your administrator rights.

Does Microsoft back up my Microsoft 365 data? Not in the way most owners assume. Microsoft guarantees the availability of the service; the data you put into it remains yours to protect. This shared responsibility model is the most common dangerous misunderstanding we encounter.

Is immutable storage expensive? No, and this surprises people. It is a feature of standard cloud object storage, priced in tens of euros per terabyte per month. The cost is the configuration, done once and done properly — not the storage.

Can an attacker defeat immutability? Not within the retention window. That is the entire point, and why the retention period must exceed a realistic dwell time. Lock a copy for seven days and a patient intruder waits it out; lock it for thirty or ninety and they cannot.