Modern ransomware operators don't just encrypt your production data. They actively hunt for and destroy backups first — because dealers, agencies, accountants, and law firms with working backups don't pay the ransom. Removing the backup is step one of a professional ransomware operation.
That's why backup design matters more than ever. The good news: the rule that defines a survivable backup is decades old, and stunningly simple.
The 3-2-1 Rule
Maintain at all times:
- 3 copies of your data — the production copy plus two backups
- 2 different storage media or platforms — don't put all backups in the same technology
- 1 copy stored off-site — geographically separate from your primary location
The modern extension — sometimes called 3-2-1-1-0 — adds:
- Plus 1 immutable or offline copy that ransomware cannot reach
- And 0 errors verified through regular restore testing
Immutable vs Offline — and Why Both Matter
Two of the most-misunderstood terms in backup design:
Immutable means the backup, once written, cannot be modified or deleted for a defined retention period — even by an administrator with full credentials. Modern object-storage platforms (AWS S3 Object Lock, Azure Blob immutability, Wasabi, Backblaze B2) support this. So do most modern backup appliances.
Offline means the backup is physically disconnected from any network when not actively being written or restored. Tape rotated to a safe. A USB drive removed from the server. A backup appliance on an air-gapped network segment. Ransomware cannot encrypt what it cannot see.
Either approach defeats the "hunt and destroy backups first" phase of a ransomware attack. Belt-and-braces operations use both.
Where Most SMBs Get It Wrong
In our assessments we see the same six backup failures over and over.
Backups on the same network as production
If a NAS, server, or shared drive holds your backups and your production data, ransomware encrypts both. Most SMB "backups" sit here.
Single backup destination
One cloud account. One USB drive. If that destination fails, is hijacked, or gets encrypted along with everything else, recovery is impossible.
No immutability
Even cloud backups can be deleted by an attacker who steals the admin credentials. Without immutable retention, attackers wipe the backups before they trigger the encryption.
Untested restore
"We have backups" is a hope. "We restored a 100GB dataset in two hours last quarter" is a fact. The first backup most SMBs ever try to restore is during an actual incident.
Backups missing critical data
Cloud apps (M365, Google Workspace, Salesforce, Dropbox) are usually NOT backed up by default. The provider replicates them — but a deletion or ransomware-encrypted file is replicated too. You need separate SaaS backup.
Long recovery windows
If restoring takes a week, you're still down a week. Modern backup design measures recovery time, not just backup completion.
What Good Looks Like for an SMB
A defensible SMB backup posture in 2026 typically looks like:
- Production: your normal servers, endpoints, file shares, and cloud apps
- Backup #1 (local): backup appliance or server on a segmented network, holding the most recent recovery points for fast restore
- Backup #2 (cloud, immutable): immutable object storage in a different cloud or region from production, retained 30–90 days
- SaaS backup: dedicated backup of M365, Google Workspace, and any business-critical SaaS — separate from the underlying provider
- Backup admin separation: backup-system credentials are NOT the same as production AD admin credentials
- Monitoring: backup job failures alert someone who'll act on them
- Testing: quarterly restore tests, annual full-recovery rehearsal
A setup like that survives most ransomware events with hours-to-days of recovery time, not weeks. And it's well within reach for any business spending $375+/month on managed cyber.
Test Before You Need To
The single highest-leverage thing you can do today is run a restore test. Pick a representative dataset, restore it to a separate environment, time the operation, and check that the restored data is actually usable. If anything fails — backup didn't complete, restore threw errors, files came back corrupted — you've learnt that for free.
Backup Testing Checklist
- Quarterly file-level restore test from each backup destination
- Annual full-system restore test to a clean environment
- Documented recovery time for a representative dataset
- Verification of M365 / Google Workspace / SaaS backup completeness
- Test of backup admin account recovery (if your only admin is compromised, can you still restore?)
- Validation that backup logs are being monitored and failures are alerting someone
What Insurance and Regulators Now Expect
Cyber-insurance applications now ask explicitly about immutability, offsite separation, SaaS backup coverage, and restore testing. The FTC Safeguards Rule, NAIC Model Law, and HIPAA Security Rule all imply requirements for backup integrity and recoverability. A "we have backups" answer doesn't pass any of these tests anymore.
The Bottom Line
The 3-2-1 rule is older than ransomware. It still works because it doesn't depend on any specific technology — only on the principle of separation. Add immutability or air-gapping for the modern attack landscape, test restoration regularly, and you've given your business the single biggest insurance against catastrophic data loss.
Related reading: If the worst happens, our incident response guide walks through the first 24 hours.
Are your backups actually ransomware-proof?
Free assessment of your backup architecture, retention, immutability, and recovery time. We'll tell you exactly what would happen tomorrow.
Get Free Assessment