Book your free backup strategy review · Prefer to self-assess? Grab the free backup checklist.
A backup only protects you from ransomware if the attacker cannot reach it, alter it, or delete it — which is why the modern standard is the 3-2-1-1-0 rule: 3 copies of your data, on 2 media types, with 1 copy offsite, 1 copy offline or immutable, and 0 errors verified by regular restore tests. Ordinary backups fail against ransomware because today's attackers deliberately find and destroy online backups before they trigger encryption. The copy that saves you is the one that is air-gapped or write-once-protected at the storage layer, so a fully compromised network still cannot touch it — combined with proof, from tested restores, that the data actually comes back.
That paragraph is the summary an AI overview would give you. The rest of this article is what the summary can't: why each digit in the rule maps to a specific ransomware tactic, how immutable and air-gapped copies actually work, and how to prove your recovery plan before you have to use it in anger.
The 3-2-1-1-0 rule at a glance
The classic 3-2-1 rule kept data safe from hardware failure and fire. It was never designed for an adversary who targets your backups on purpose. The two extra digits — the second 1 and the 0 — close exactly that gap.
Read the diagram left to right. The first three digits are the traditional resilience rule. The amber digits — one offline/immutable copy and zero errors — are the ransomware-specific hardening. When an attack detonates, everything reachable on the network can be encrypted at once (including a naïve cloud sync). The copy that comes back is the one the attacker was never able to touch, and the "0" is your proof it will actually restore.
Why ransomware beats ordinary backups
Understanding the defense starts with understanding the attack. Modern ransomware is not a smash-and-grab; it is a patient operation:
- Initial access through phishing, an exposed service, or stolen credentials.
- Lateral movement — the attacker escalates privileges and maps the environment. A primary goal at this stage is finding your backups.
- Backup destruction — before triggering encryption, they delete snapshots, wipe or encrypt backup shares, and revoke cloud backup credentials. This is deliberate: a working backup is the one thing that defeats their leverage.
- Detonation — only then do they encrypt production, because now you have nothing to fall back on.
The lesson is uncomfortable but clarifying: any backup that is reachable over the network with normal credentials is part of the attack surface, not the recovery plan. A nightly job writing to a NAS the domain admin can browse to, or a cloud folder that continuously syncs, offers no protection against an adversary who already owns the domain admin account. The rest of this article is about building the copy they can't get to — and proving it works.
Each principle mapped to the ransomware tactic it defeats
This is the table an AI summary won't build for you: every backup principle paired with the specific attacker behavior it neutralizes.
| Principle | What it means in practice | Why ransomware can't beat it |
|---|---|---|
| 3 copies | Production plus at least two backups, so no single failure loses everything | Redundancy means destroying one copy doesn't destroy your recovery — the attacker has to reach all of them |
| 2 media types | Store copies on different technologies (local disk, cloud object storage, tape) | Different media have different access paths and credentials, so one compromised system can't reach every copy |
| 1 offsite | At least one copy physically away from the primary site | Isolates recovery data from a site-wide encryption event, fire, or physical seizure |
| 1 offline / immutable | An air-gapped copy or write-once (WORM/object-lock) copy that cannot be altered for a retention period | This is the decisive control: even a full domain-admin compromise cannot encrypt or delete a locked or disconnected copy |
| 0 errors | Every backup verified; restores tested on a schedule | Guarantees the surviving copy actually restores — untested backups routinely fail silently exactly when needed |
| MFA on the backup console | Multi-factor auth and separate credentials for the backup platform | Stops the common path where stolen admin credentials are used to disable jobs and purge recovery points |
| Monitoring & alerting | Automated alerts on failed jobs, unexpected deletions, or retention changes | Surfaces an attacker tampering with backups before detonation, buying response time |
The single highest-impact row is 1 offline / immutable. If you do nothing else this quarter, make one copy immutable.
Immutable backups: the control that actually works
An immutable backup is written once and cannot be changed or deleted until its retention period expires — enforced below the operating system, at the storage layer. Because the lock lives in the storage platform rather than in your servers, credentials that compromise the servers are useless against it.
You get immutability from:
- Object lock (WORM) on cloud object storage — Amazon S3 Object Lock, Azure immutable blob storage, Google Cloud Bucket Lock, or S3-compatible providers with lock support. Recovery points are stamped with a retention date and physically cannot be overwritten before it passes.
- Hardened backup appliances that expose immutable repositories, keeping the lock enforcement out of reach of the general-purpose OS.
- Snapshot immutability on storage arrays and some SaaS backup platforms, where snapshots are protected from deletion for a set window.
The critical configuration detail: immutability must be switched on and given a retention period longer than your worst-case detection time. If ransomware dwells in your environment for three weeks before triggering and your immutable retention is only seven days, the clean recovery points may have already aged out. Set retention to comfortably exceed realistic dwell time.
Air-gap and offline copies
Where immutability makes a copy unchangeable, an air gap makes it unreachable. Two forms both work:
- Physical air gap — removable media (tape or rotated external drives) stored offline. Malware has no network path to media that is physically disconnected. Tape remains popular for exactly this reason: an ejected tape is unhackable.
- Logical air gap — network isolation plus separate credentials and time-boxed access, so the backup target is reachable only during the backup window and invisible the rest of the time. Done well, this approximates a physical gap while staying automated.
Immutable and air-gapped are not mutually exclusive — the strongest posture combines them: an offsite, immutable, logically-isolated copy for fast recovery, plus a periodic true-offline copy for the deepest fallback.
The "0": test your restores or you don't have backups
The final digit is the one most organizations skip, and it is the one that turns a backup strategy into a recovery strategy. A backup that has never been restored is an assumption. Silent corruption, incomplete job scope, missing application-consistency, and expired immutability all fail quietly — and you discover them mid-incident, which is the worst possible time.
Build a restore-test discipline:
- Schedule real restores — quarterly at minimum, monthly for critical systems, and after any significant infrastructure or backup-config change.
- Restore to an isolated environment and actually boot or open the data, don't just confirm the job "completed."
- Measure recovery time and compare it against your RTO target; measure how much data you'd lose against your RPO.
- Document and fix every gap the test exposes.
Estimating how long a full restore will actually take — and whether it fits your recovery window — is where planning gets concrete. This calculator models it from your data volume and restore throughput:
Lock down the backup console
Your backup platform is the master key to every recovery point, which makes it a primary target. Harden it as you would a domain controller:
- Enforce MFA on every backup console login — ideally phishing-resistant factors (FIDO2/WebAuthn).
- Use separate credentials from your everyday domain admin accounts, so a compromised Windows admin doesn't automatically own the backups.
- Apply least privilege — few people need the power to change retention or delete recovery points.
- Alert on dangerous actions — retention shortening, mass deletion, job disabling — so tampering is visible before detonation.
Putting it together: a ransomware-resistant baseline
For a small or mid-sized organization, a defensible baseline looks like this:
- 3 copies: production, a local backup for fast restores, and a cloud copy.
- 2 media: local disk plus cloud object storage (add tape for the deepest tier if regulation or risk warrants).
- 1 offsite: the cloud copy, geographically separate from the primary site.
- 1 immutable/offline: object lock on the cloud copy with retention beyond your worst-case dwell time — plus, ideally, a periodic true-offline copy.
- 0 errors: scheduled, tested restores that validate both the data and your RTO.
- MFA + separate credentials on the backup console, with alerting on retention and deletion changes.
Layer disaster recovery on top — the ability to spin recovery workloads up quickly, often via virtualization — and a ransomware event becomes a restore operation instead of an existential crisis. Where those copies should physically live, and the cost trade-offs between on-premises and cloud, is its own decision: see cloud vs. on-premises backup for modern SMBs.
Frequently Asked Questions
The FAQs below are also available as structured data for search engines and AI assistants.
Book your free backup strategy review
We'll review your current backup and recovery posture against the 3-2-1-1-0 standard and give you a clear, no-obligation risk report.