The scenario plays out the same way in every incident: at 03:00 an attacker gets in through an exposed VPN or an RDP account with a weak password, moves laterally across the network for a few days without being noticed and, before encrypting the production files, does one single thing — deletes the backups. Only then does the encryption begin. In the morning the SME discovers that both the server is locked and the safety copies are useless.
That is the reality of modern ransomware: simply having a backup is no longer enough. You need a backup that no one — not even a compromised administrator — can delete or modify for a guaranteed period. That is the immutable backup, and for an SME processing invoices, orders or patient data, it is the difference between a few hours of downtime and going out of business.
In this guide I'll show you concretely what immutability means, how to apply the 3-2-1 rule correctly (and its modern variant), how to isolate your copies, and the steps a well-prepared SME follows in the first hours after an attack.
1. Why classic backup fails against ransomware
Most SMEs believe they are protected because they have a "backup". The problem is where and how. Attackers who deploy ransomware no longer encrypt at random — they operate as a team, carry out reconnaissance and explicitly hunt for the backup infrastructure, because they know that a successful restore wipes out their ransom demand.
Here are the backup patterns that fall most often:
- A NAS mapped as a network drive — if the server sees the backup as a drive letter (
Z:\), then so does the ransomware. It encrypts the files on the NAS exactly like the rest. - Backup on the same domain / same credentials — a compromised domain administrator account also has access to the backup console. The attacker deletes the jobs and the retention with a few clicks.
- Snapshots on the same hypervisor — useful for human error, useless when the entire ESXi/Hyper-V host is compromised (an increasingly common vector).
- Cloud sync ≠ backup — synced OneDrive, Google Drive or Dropbox means the encrypted files propagate to the cloud. Syncing replicates the disaster; it does not save you from it.
Syncing is not backup. A file synced to the cloud that has been encrypted locally will become encrypted in the cloud within seconds. A backup implies historical, immutable versions that today's encryption cannot reach.
2. What an immutable backup actually is
An immutable backup is a copy of data that, once written, can no longer be modified or deleted for a defined period — regardless of who issues the command. Not the administrator, not a compromised account, not malware running with maximum privileges. The technical mechanism is usually called WORM (Write Once, Read Many).
How immutability is achieved in practice
- Object Lock in S3-compatible storage — services such as Wasabi, Backblaze B2 or Amazon S3 offer a "lock" at the object level. You set a retention period (for example 14 or 30 days) and, until it expires, the object cannot be overwritten or deleted, even if someone holds the API keys.
- An immutable repository in your backup software — Veeam on a Linux hardened repository, Veeam with Object Lock in the cloud, or similar solutions that mark the blocks as immutable.
- Immutable snapshots on enterprise storage — many modern NAS/SAN solutions allow "locked" snapshots that not even the administrator can delete before the term is up.
- LTO tape removed from the library — the classic physical air-gap: a disconnected cartridge cannot be touched by any remote attack.
The crucial point: immutability must be guaranteed by the storage platform, not just a "read-only" setting in your backup software. A simple "protected" tick box that someone with admin rights can untick is not real immutability.
Initial access (phishing / RDP / VPN) → lateral movement 2-10 days → data exfiltration for double extortion → deletion of accessible backups → encryption of production → ransom note. The immutable backup is the one link the attacker cannot break in step four.
3. The 3-2-1 rule and the 3-2-1-1-0 variant
The 3-2-1 rule is the foundation of any serious backup strategy and reads simply:
- 3 copies of your data (production + 2 backups)
- 2 different types of storage media (for example local disk + cloud / tape)
- 1 copy kept in another location (offsite)
In the ransomware context, the rule has been extended to 3-2-1-1-0, adding two critical requirements:
- 1 offline or immutable copy (air-gapped / WORM)
- 0 errors on restore verification — a tested backup, not one merely assumed to work
| Layer | Where | Primary role | Immutable? |
|---|---|---|---|
| Copy 1 (production) | Server / VPS | Live data | No |
| Copy 2 (local) | NAS / on-prem repository | Fast restore | Recommended |
| Copy 3 (offsite) | Cloud S3 with Object Lock | Disaster recovery | Yes (mandatory) |
In practice, for a typical SME, the working configuration is: a local backup on an isolated repository for day-to-day restores (low RTO), plus an immutable offsite copy in the cloud with Object Lock, as an anti-ransomware safety net. To design these layers correctly, we work on the IT infrastructure and storage side together with the cybersecurity team.
Set different retention periods per layer: daily copies of 14-30 days for fast restores, plus weekly/monthly immutable copies of 3-12 months. Many attacks sit "dormant" in the network for several weeks — too short a retention leaves you with no clean point to restore from.
4. Real isolation: air-gap, WORM and separate accounts
Immutability solves half the problem (it cannot be deleted). Isolation solves the other half: the attacker must never reach the backup console at all. The combination of the two is what makes an SME truly resilient.
Logical and physical air-gap
An air-gap means the backup is not directly accessible from the production network. Physically, it is an LTO tape removed from the drive. Logically, it is a cloud repository accessible only through dedicated API keys, never mapped as a drive and never on the same domain as the servers.
Separate accounts and credentials
- The backup console has its own accounts, which are NOT part of the production Active Directory.
- Multi-factor authentication (MFA) is mandatory on the cloud portal and on the backup software.
- The API keys writing to the immutable storage do not permit deletion (the "append-only" principle).
- An immediate alert fires on any attempt to change the retention policy.
Hardened repository
A backup repository on a hardened Linux box (minimal services, restricted SSH, no access from the main network) is far harder to compromise than a Windows share. On this server, the backup software holds exclusive control over the files — not even the root account can delete them before the immutability term expires.
5. Recovering after an attack: the correct order of steps
An immutable backup guarantees you have somewhere to restore from. But a badly executed recovery can re-infect the clean environment. The order matters enormously:
- Isolate, don't shut down blindly. Disconnect the affected systems from the network, but keep them powered on for forensic analysis if possible. Shutting down can destroy evidence held in memory.
- Identify the vector. Do not restore before you know how the attacker got in — otherwise you restore onto the same open hole and get encrypted again.
- Build a clean environment. New / reinstalled servers, fully rotated passwords, MFA everywhere, before any restore.
- Restore from the immutable copy, choosing a point prior to the compromise (this is where long retention pays off).
- Scan the restored data before reconnecting it to production.
- Bring services back gradually and monitor intensively for the first few days.
If the backups were affected too, or partially corrupted, specialist recovery comes into play: in many cases data can be extracted from partially encrypted volumes or from residual snapshots. This is where we work on the data recovery side, but the honest message is that prevention through immutability costs tens of times less than an emergency recovery.
Paying the ransom does not guarantee decryption and marks you as a "paying" target. A tested immutable backup means you never end up in the position of having to negotiate. Check first what you can restore.
6. What an SME should do, concretely
If you are a manager or an IT person in an SME and you want to close off this risk, here are the steps in the order in which they matter:
- ✅ Inventory which data is critical (invoicing, ERP, customer databases, email) and define realistic RPO and RTO targets for each.
- ✅ Implement the 3-2-1-1-0 rule, with at least one immutable offsite copy (Object Lock in the cloud).
- ✅ Fully separate the backup credentials from the production Active Directory and enable MFA.
- ✅ Set tiered retention (short dailies + longer immutable monthlies).
- ✅ Test the restore for real, monthly — a complete trial restore, not just confirming the job "ran".
- ✅ Document an incident response plan: who to call, what to disconnect, where to restore from.
- ✅ Combine the backup with basic security hygiene: patching, network segmentation, EDR and email filtering.
An immutable backup is not a product you tick off and forget — it is a discipline. But it is, without exaggeration, the best resilience investment an SME can make. The rest of your security measures reduce the probability of an attack; a tested immutable backup reduces the impact to almost zero. See also our anti-ransomware protection options or the cost details on our pricing page.