Ransomware crews know that backups are what stand between them and a payment. So they go after the backups first. They delete cloud snapshots, wipe the backup server, and encrypt the NAS before they touch a single user file. A backup that the attacker can reach is not a backup. It is a target.
The 3-2-1-1-0 rule is the modern version of the old 3-2-1 advice, extended for a world where the person deleting your backups has your Domain Admin password.
What each number means
The rule is short enough to remember and specific enough to audit. Walk down the list for every system you care about and check each box honestly.
- 3 copies of the data: production plus two backups. Production counts as one.
- 2 different media or platforms: not two folders on the same NAS. A backup repository on disk and a copy in object storage, for example.
- 1 copy offsite: a different building, a different cloud region, or a different provider. If the office floods or the whole tenant is taken over, this is the copy that survives.
- 1 copy immutable or offline: a copy that cannot be modified or deleted by anyone, including an administrator, for a set retention period. Or a copy that is physically disconnected.
- 0 errors on restore verification: the backup job finishing is not the same as the data being restorable. Verified restores are the only proof.
Immutable means immutable to you, too
Immutability is the piece most small businesses are missing, and it is the piece that matters most in a ransomware event. An immutable backup is one where the storage layer refuses deletion or modification until a retention clock runs out, regardless of who asks. Not the backup software. The storage.
That distinction matters because the attacker will have the backup software credentials. If deletion is enforced only by the backup application, a stolen admin login defeats it. If it is enforced by the storage underneath, the attacker can delete the backup job and the repository entry and the data is still there when the clock says so.
- Object storage with Object Lock in compliance mode: AWS S3, Wasabi, Backblaze B2 and Azure Blob with immutability policies all support this. Veeam, Synology Hyper Backup and most modern backup tools can write to it.
- A hardened Linux repository: Veeam's Hardened Repository uses an immutable flag on the file system and single-use credentials. The backup server cannot delete from it.
- Snapshot locking on the NAS: Synology Snapshot Replication supports immutable snapshots, as do most enterprise SAN platforms.
A practical layout for a small company
Here is a design that satisfies the rule without an enterprise budget. Adjust the names to your tools; the shape is what matters.
The critical property is that no single credential can destroy all copies. The backup server can write to the local repository. Only the object storage account can touch the cloud copy, and that account cannot delete during the lock period.
- Copy one: production data on your servers and in Microsoft 365.
- Copy two: nightly image-level backups of every VM and physical server to a local repository on separate hardware, retained 30 days. Fast restores come from here.
- Copy three: a backup copy job sends the same restore points to object storage with Object Lock set to 30 days. This is offsite and immutable in one step.
- Microsoft 365: a separate SaaS backup product that captures Exchange, OneDrive, SharePoint and Teams. Microsoft's retention is not a backup and cannot restore a deleted tenant.
- Domain controllers and configuration: export a System State backup weekly and store firewall, switch and hypervisor configs in the same immutable bucket.
- Encrypt everything in transit and at rest, and store the encryption key somewhere that is not the backup server.
Isolate the backup server itself
Most backup servers are domain joined, logged into with Domain Admin, and reachable from every workstation. That makes them the easiest target in the building. The attacker who gets Domain Admin gets the backups for free.
Treat the backup infrastructure as its own security zone.
- Do not domain join the backup server, or put it in a separate forest. Use local accounts with unique passwords.
- Put it on its own VLAN. Allow inbound only from the hypervisor hosts and the ports the backup agent needs. Deny inbound RDP from user networks.
- Give the backup service account read access to production, never write. It needs to copy data out, not change it.
- Enable MFA on the backup console if the product supports it, and alert on job deletions and retention changes.
Frequently asked questions
Is a cloud sync like OneDrive or Dropbox a backup?
No. Sync copies changes, including encryption and deletion, to every device and to the cloud within minutes. Version history helps for a single file but is not designed to roll back an entire tenant. Use a dedicated backup product that writes to storage the sync client cannot reach.
How long should the immutability period be?
Longer than the time it takes you to notice a problem. Attackers often sit in a network for weeks before encrypting, so a 7 day lock can expire before you know you need it. Thirty days is a reasonable floor for most businesses; longer if you have the storage budget.
We already have a NAS with RAID. Is that not redundant enough?
RAID protects against a disk failing. It does nothing against deletion, encryption, fire, theft or a firmware bug. All copies on one NAS are one copy for the purposes of this rule.
Takeaway
Count your copies honestly, put one of them somewhere no administrator credential can delete it, and prove you can restore from it. That is the whole rule. If you do those three things, ransomware becomes an outage instead of a negotiation. If you want someone to review your current setup against the rule, RackLedge does backup design reviews as a fixed-scope engagement.