The 3-2-1-1-0 backup rule: ransomware protection for SMBs

Many businesses believe they "have backups" until the day they need to restore. That is when they discover the NAS holding the backup copy was encrypted too, the backup job has been failing for three weeks with nobody reading the alerts, or a full server restore takes two days instead of the few hours they expected.

Ransomware has changed the backup problem. This post explains the 3-2-1-1-0 rule, why it fits the current threat landscape, and how a small or mid-sized business can implement it step by step.

How ransomware changed the backup problem

Backups used to be insurance against failed disks and accidental deletes. Today, ransomware groups typically break in, lie low while they map the network, delete or encrypt the backups first, and only then encrypt the primary data. Weak points that get exploited:

• The backup share is already mapped as a network drive on the server

• The backup server is joined to the same domain with a shared admin account

• The only copy sits on the same internal network as the original data

• Cloud sync software faithfully syncs the encrypted files too

In recent years the press has reported many businesses in Vietnam, including listed companies, pausing operations for days because of ransomware. On top of that, the Personal Data Protection Law (No. 91/2025/QH15, effective from 01/01/2026) sets requirements for protecting personal data during processing. A dependable backup strategy is therefore not just a technical issue — it is part of the business's obligations.

What is the 3-2-1-1-0 rule?

The familiar 3-2-1 rule gains two extra numbers:

Immutable and offline copies

This is the second "1" — and the most important layer against ransomware.

An immutable copy is one that, for a pre-set retention period, cannot be modified or deleted by anyone, not even an admin account. Common approaches:

• S3-compatible object storage with Object Lock. In compliance mode, even the root account cannot delete the object before the lock expires.

• A hardened backup repository on Linux that only accepts new writes and blocks deletions from the backup server side.

An offline (air-gapped) copy is one with no network connection: rotating external drives stored elsewhere, or tape. It is cheap, but it depends on operational discipline: who swaps the drives, how often, and where they are kept.

Some principles that go with it:

• Backup admin accounts separated from the domain, with MFA enabled

• A lock period long enough to detect an intrusion, not just a few days

• Backups encrypted, with the decryption key stored safely apart from the primary systems

RPO and RTO: two numbers to agree on first

• RPO (Recovery Point Objective): the maximum amount of data the business accepts losing, measured in time. An RPO of 24 hours means backing up every night and potentially losing a full day of work.

• RTO (Recovery Time Objective): the maximum time a system may stay down after an incident.

RPO determines backup frequency; RTO determines the recovery method and the infrastructure required. Illustrative starting points to adapt per business:

The shorter the RPO and RTO, the higher the cost. Agree on these numbers with management — do not let IT decide alone.

The 0: restore testing

"Backup succeeded" in a report does not mean the data restores. A sensible testing plan for an SMB:

• Daily: read the backup job reports; act on failures and alerts right away.

• Monthly: restore a random selection of files, a mailbox, or a database copy into a test environment.

• Quarterly: restore one complete critical server (e.g. the ERP) into an isolated environment and measure the actual time against the RTO.

• Annually: run a ransomware drill — assume the whole internal network is unusable and only the immutable copy remains.

Every test needs a written record: what was restored, how long it took, what errors occurred, and who signed off that the data was correct.

Common mistakes

• Treating sync as backup. Sync copies the bad changes too, including encrypted or deleted files.

• Forgetting SaaS data. Email and cloud storage providers are responsible for their infrastructure, but restoring deleted or encrypted data is usually the customer's responsibility — and limited by retention windows.

• Backing up data but not configuration. Firewall and switch configs, licences, network diagrams and the restore-order documentation also need to be kept.

• Nobody is responsible for reading alerts. Backups failing silently for weeks is a common story.

An implementation roadmap for SMBs

1. Inventory: list the systems, data, storage locations and current backup methods.

2. Set targets: agree RPO and RTO for each group of systems.

3. Add the missing layers: an off-site copy and an immutable or offline copy; separate backup admin accounts.

4. Operate and test: monitor jobs daily, a restore-testing schedule, recovery runbooks.

The 3-2-1-1-0 backup checklist

• [ ] At least 3 copies exist for every critical system

• [ ] Copies sit on at least 2 types of storage media

• [ ] At least 1 copy is kept off-site

• [ ] At least 1 copy is immutable (object lock, hardened repository) or offline

• [ ] Backup admin accounts are outside the domain and have MFA

• [ ] Backup shares are not mapped on servers or workstations

• [ ] RPO and RTO have been approved by management

• [ ] Someone reads the backup reports every day

• [ ] Monthly and quarterly restore tests are scheduled and documented

• [ ] A recovery runbook exists and has been drilled at least once

Are you sure you can restore?

The fastest way to find out whether your backup strategy works is to restore a critical system and time it. If you want to review your current backup setup, find the gaps against the 3-2-1-1-0 rule and plan improvements that fit your budget, contact SYSMAN to talk it through.