Published July 8, 2026 · Last updated July 10, 2026
- The 3-2-1-1-0 backup rule upgrades the classic 3-2-1 rule for the ransomware era: it adds one immutable or air-gapped copy that stays safe even if an attacker steals your admin credentials, plus a “0” that demands zero errors on tested restores.
- The make-or-break digit is the immutable “1” — WORM storage such as S3 Object Lock in Compliance mode, where no one (not even the cloud root account) can delete or alter a copy until its retention window expires.
- Almost everyone skips the “0”: automate post-backup integrity checks, do monthly spot-restores, and run an annual full-recovery drill that times your real recovery window — because an untested backup is only a hope, not a backup.
If a backup you have never tested fails the moment you actually need it, you did not have a backup. You had a hope. That single hard truth is why the old advice most people half-remember has quietly grown two extra digits. The 3-2-1-1-0 backup rule is the modern, ransomware-aware upgrade to a strategy that has protected data for two decades, and the good news is that every one of its five numbers maps to something you can set up this weekend, whether you are protecting a laptop full of family photos or the file server that runs a small business.
Here is the short version before the deep dive: keep 3 copies of your data, on 2 different kinds of media, with 1 copy offsite, plus 1 copy that is immutable or air-gapped so ransomware cannot touch it, and you finish with 0 verification errors because you actually test your restores. The rest of this guide decodes each digit in plain English, then shows you exactly how to implement it at home and at a small business, including the parts most articles skip: how immutability really works under the hood, and what a restore-test routine actually looks like.
What Is the 3-2-1 Backup Rule? (The Foundation You Are Upgrading)
Before you can understand the two new digits, you need the original three. The 3-2-1 backup rule was popularized in the late 2000s by photographer Peter Krogh, who needed a memorable way to keep irreplaceable image libraries safe, and it has since become the default recommendation from vendors and security agencies alike. Backblaze’s widely cited explainer breaks it down the same way it is taught today.
- Three copies of your data, full stop. This means your live working copy plus two backups, not one backup that you mentally count twice. The logic is statistical: the odds of one drive failing in a given year are real, but the odds of three independent copies all failing at the same moment are vanishingly small. If you only keep an original and a single backup, one bad weekend (a dropped laptop and a backup drive that silently died months ago) wipes you out completely.
- Two different types of media or devices. Putting all three copies on identical drives from the same manufacturer batch is a hidden single point of failure, because drives from one batch can share a defect and fail in a cluster. Spreading copies across, say, an internal SSD, a spinning-disk NAS, and cloud object storage means no single media flaw, firmware bug, or controller failure can take down everything at once.
- One copy offsite, ideally miles away. A fire, flood, burst pipe, or burglary does not politely skip your backup drive sitting on the same desk as your computer. An offsite copy survives the physical destruction of your home or office, which is the entire point of the digit. “Offsite” can mean cloud storage, a drive at a relative’s house, or a rotation drive in a safe-deposit box, as long as it is not in the same building as the original.
The 3-2-1 rule is still excellent, and if you do only this you are already ahead of most people. But it was designed in an era when the main threats were hardware failure, theft, and natural disaster. It assumed an attacker could not reach across your network and deliberately corrupt all three copies at once. That assumption no longer holds, which is where the two new digits come in.
What Ransomware Changed in 3-2-1 vs 3-2-1-1-0
The jump from 3-2-1 to 3-2-1-1-0 is not a marketing rebrand; it is a direct response to how modern ransomware behaves. The reason this matters is mechanical, not theoretical.
Early ransomware simply encrypted whatever it could find on the infected machine. Modern ransomware crews are patient and methodical: after gaining access, they spend days or weeks moving laterally through the network, escalating privileges, and specifically hunting for backups, because they know an organization with good backups will never pay the ransom. They will find your network share, your connected backup drive, and even the credentials to your backup software, and they will encrypt or delete those copies first, then trigger the main attack. A classic 3-2-1 setup where all copies are online and reachable can be neutralized in a single coordinated strike. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) consistently emphasizes maintaining offline, encrypted backups for exactly this reason in its ransomware guidance.
That threat model is why the extra digits exist, as TechTarget explains in its breakdown of how the 3-2-1-1-0 rule reflects modern needs:
- The extra “1” makes at least one copy unreachable by an attacker. It must be immutable (cannot be altered or deleted for a set period, even with valid credentials) or air-gapped (physically or logically disconnected from the network). This is the copy that survives when everything online is encrypted, and it is the difference between a bad week and a closed business.
- The “0” forces you to prove the backups work. A copy that exists but cannot be restored is worthless, and ransomware sometimes corrupts backups slowly before detonating. Demanding zero verification errors turns “I think we have backups” into “we have confirmed, restorable backups as of last night.”
If you want a deeper, defense-focused walkthrough of building backups that survive an active attack, our guide to ransomware-proof backups covers the recovery side in detail. For now, the takeaway is simple: the 3-2-1-1-0 backup rule assumes someone is actively trying to destroy your backups, and it builds in two safeguards specifically to defeat that.
Why the First Extra Copy Goes Offsite
The original offsite digit is about geography, and it remains the cheapest insurance you can buy against the events most likely to actually happen to you: a house fire, a flooded basement, a stolen bag, or a server room sprinkler that goes off at 2 a.m. The mechanism is brutally simple, which is what makes it reliable.
- For home and prosumer users, cloud sync is the path of least resistance. A service like Backblaze Personal, iDrive, or an encrypted Backblaze B2 / Amazon S3 bucket continuously ships an offsite copy without you remembering to do anything. The thing to watch is the first upload: backing up 2 TB of photos over a typical home connection can take days to weeks, so start it before you need it, and verify the service has actually finished the initial seed rather than assuming it is done.
- A rotation drive at a second location is the no-subscription alternative. Keep two external drives, back up to one, store it at a relative’s house or in an office desk drawer, and swap them every week or two. The consequence to plan for is the gap: whatever changed since your last swap is not offsite yet, so this method pairs well with a smaller real-time cloud copy of only your most critical files.
- Small businesses should treat offsite as a recovery-time decision, not just a storage decision. It is not enough to know the data is in the cloud; you need to know how long it takes to pull 500 GB back down and how much that egress costs. Cold-storage tiers are cheap to hold but slow and pricey to retrieve in a crisis, so keep recent, business-critical backups in a standard-access tier and push only older archives to the cheapest cold tier.
A practical detail people overlook: encrypt before it leaves the building. An offsite copy is, by definition, outside your physical control, so client-side encryption (you hold the key) ensures that a breach of the cloud provider or a stolen rotation drive does not become a breach of your data.
How Immutable and Air-Gapped Backups Work
This is the digit that defeats ransomware, and it is the one most worth understanding correctly, because vendors use the words “immutable” and “air-gapped” loosely. They describe two different ways to reach the same goal: a copy that an attacker with full access to your systems still cannot destroy.
How WORM and Object Lock Make Backups Immutable
Immutable means write-once-read-many (WORM): once written, the data cannot be modified or deleted until a retention clock expires, even by someone holding administrator credentials. This is enforced by the storage platform itself, not by your backup software, which is what makes it resistant to stolen logins.
The clearest real-world implementation is Amazon S3 Object Lock, and understanding it teaches you the whole concept:
- It runs in two modes, and the distinction is the whole point. In Governance mode, objects are protected from deletion by ordinary users, but an account holder with a special bypass permission can override it; this is good for guarding against mistakes. In Compliance mode, no one can delete or overwrite the object before its retention period expires, including the AWS root account holder, and the retention period cannot be shortened. Compliance mode is the genuine ransomware safeguard, because even an attacker who steals your root credentials hits a wall.
- Object Lock requires versioning and applies per object version. Locking depends on S3 Versioning being enabled, and the lock protects the specific version you wrote. A “delete” on a locked object simply adds a delete marker over the top; the locked version underneath survives intact until its clock runs out, so your clean copy is always recoverable.
- Retention periods and legal holds are different tools. A retention period is a fixed window (say, 30 days) after which the object becomes deletable again. A legal hold has no expiry and stays until explicitly removed. For backups, a rolling retention period sized to your recovery needs is the normal choice, because it keeps a window of clean copies while letting truly old data age out.
The same WORM idea appears across providers under different names: Azure offers immutable blob storage with time-based retention and legal-hold policies, Wasabi offers Object Lock compatible with the S3 model, and Backblaze B2 supports Object Lock as well. The principle is identical everywhere: pick a true immutable/compliance-style lock, set a retention window at least as long as it would realistically take you to discover an intrusion (often 14 to 30+ days), and an attacker simply cannot delete those copies within the window.
Air-Gapped Backup as the Offline Cousin
An air-gapped backup reaches the same safety through physical or logical disconnection rather than software-enforced immutability. The reasoning is that ransomware cannot encrypt what it cannot reach.
- A true physical air gap means the media is offline most of the time. A rotated external drive that is plugged in only during the backup window, or an LTO tape ejected and stored in a cabinet, is unreachable by malware for the hours or days it sits disconnected. The trade-off is that air gaps require discipline or automation; a “backup drive” left permanently plugged into the server is not air-gapped at all and will be encrypted along with everything else.
- A logical air gap simulates disconnection on always-on systems. Some repositories are exposed only through a narrow, hardened protocol and stay inaccessible to the production network except during tightly controlled backup operations, giving much of the protection of a physical gap without manually unplugging anything.
For a home user, the most accessible air-gapped copy is an external drive that lives in a drawer and gets plugged in once a week. For a small business, an immutable cloud bucket usually wins because it air-gaps logically without anyone remembering to swap hardware. Many mature setups use both: an immutable cloud copy plus a periodic offline drive, so even a cloud-account compromise is not the end.
How to Test Your Backups for Zero Errors
The zero is the digit that turns a backup strategy into an actual recovery capability, and it is the one almost everyone skips. Zero means zero errors: you verify, on a schedule, that your backups are complete, uncorrupted, and genuinely restorable. The reason this is non-negotiable is that backup failures are usually silent. A job reports “success” while quietly skipping locked files, a drive develops bad sectors that corrupt older archives, or a configuration change stops protecting a critical folder, and you discover none of it until the day you desperately need a restore.
A Restore-Test Routine You Can Actually Run
- Automate integrity verification so the software checks itself. Modern backup tools can re-read backed-up data and compare checksums or hashes against the source to confirm nothing was corrupted in transit or at rest. Turn this on, schedule it to run after each backup, and configure email or push alerts on failure so a bad job screams instead of whispering. The number you want to see is literally zero failed/inconsistent items.
- Do a real test restore on a fixed cadence, not “someday.” Once a month, pick a few representative files and one larger folder, restore them to a scratch location, and open them to confirm they are genuine and current. Quarterly, do a fuller restore of a meaningful dataset. The thing to watch is silent staleness: a file that restores but is three months out of date means your job stopped capturing changes, which only a content check catches.
- For small businesses, test the full recovery, including time. Once or twice a year, perform a complete restore of a critical system to spare hardware or a virtual machine, and time it end to end. This is the only way to know your real Recovery Time Objective; discovering that a “30-minute restore” actually takes nine hours during a live outage is a career-defining surprise you want to have in a drill, not a disaster.
- Test the immutable copy specifically. It is not enough that the locked bucket exists; restore from it at least once to confirm your team knows the procedure and the credentials and tooling work. Attackers count on you never having practiced recovery from your last-resort copy.
A backup you have restored from is a backup you can trust. Until then, treat every untested backup as unproven.
A Worked Home / Prosumer Example
Picture a household with one main laptop, a partner’s laptop, and roughly 1.5 TB of irreplaceable photos and documents. A complete, affordable 3-2-1-1-0 build looks like this:
- Copies (3): the live data on each laptop, a copy on a home NAS, and a copy in the cloud. That is three independent copies, and adding the laptops’ own data means more than three in practice.
- Media (2): internal laptop SSDs, spinning disks in the local NAS, and cloud object storage make three distinct media types, comfortably clearing the two-media bar.
- Offsite (1): an encrypted cloud backup (Backblaze Personal, iDrive, or a B2/S3 bucket) handles offsite automatically once the initial seed completes.
- Immutable/air-gapped (1): enable Object Lock on the cloud bucket for a 30-day retention window, and keep one USB drive that you plug in every Sunday for a manual backup, then unplug and store in a drawer. The drawer drive is your physical air gap; the locked bucket is your immutable copy.
- Zero errors (0): turn on the NAS backup app’s integrity check, set a calendar reminder to restore a handful of photos and a tax document on the first of each month, and confirm they open. Total ongoing cost is roughly a few dollars a month plus one drive, for a setup that survives a fire, a theft, a dead drive, and a ransomware infection.
A Worked Small-Business Example
Now picture a ten-person firm with a file server holding about 4 TB of client work, plus cloud email and a line-of-business application. A defensible 3-2-1-1-0 build:
- Copies (3): production data on the server, a local backup appliance on-premises for fast restores, and a cloud copy for offsite and immutability. Email and SaaS data get their own dedicated backup, since the provider’s “uptime” is not the same as your “I can restore a deleted folder.”
- Media (2): server storage, the on-prem appliance’s disks, and cloud object storage satisfy the media-diversity requirement.
- Offsite (1): the cloud copy lives in a different region from the office, and recent backups stay in a standard-access tier so a real recovery is not throttled by cold-storage retrieval delays.
- Immutable/air-gapped (1): the cloud repository uses Compliance-mode Object Lock (or the equivalent Azure immutable blob / Wasabi Object Lock) with a retention window long enough to outlast a stealthy intrusion, commonly 14 to 30 days. Even if an attacker steals domain-admin and backup-console credentials, those locked copies cannot be deleted.
- Zero errors (0): automated post-job integrity verification with alerting, monthly spot-restores, and a documented annual full-recovery drill to spare hardware that measures actual recovery time. The drill output is a one-page report leadership can read, which is exactly what an auditor or a cyber-insurance underwriter will ask to see.
Frequently Asked Questions
What Is the Difference Between 3-2-1 and 3-2-1-1-0?
The 3-2-1 rule asks for three copies, two media types, and one offsite copy, and it defends well against hardware failure, theft, and natural disasters. The 3-2-1-1-0 backup rule adds one immutable or air-gapped copy (so ransomware cannot delete your backups) and a final zero meaning zero verification errors (so you have proven the backups actually restore). In short, 3-2-1 assumes accidents; 3-2-1-1-0 assumes a determined attacker is also trying to destroy your backups.
Is an Immutable Backup the Same as an Air-Gapped Backup?
No, though they aim for the same outcome. An immutable backup uses software- or storage-enforced WORM rules (like S3 Object Lock in Compliance mode) so the data cannot be deleted or changed until a retention period expires, even by an administrator. An air-gapped backup is physically or logically disconnected from the network so malware cannot reach it at all. Many strong setups use both, because each guards against a different failure: stolen credentials versus a fully compromised network.
How Long Should My Immutability Retention Period Be?
Set it longer than the time it would realistically take you to notice an intrusion, since attackers often lurk before striking. A common practical range is 14 to 30 days for general protection, with some organizations going longer for compliance reasons. The goal is to guarantee that when you discover an attack, at least one full set of clean, undeletable backups from before the compromise still exists inside the locked window.
Can I Achieve 3-2-1-1-0 at Home Without Spending a Lot?
Yes. A home NAS or even a second external drive provides a second media type, an inexpensive cloud backup with Object Lock enabled covers offsite plus immutability, and a USB drive you plug in weekly and store in a drawer gives you a physical air gap. The zero costs nothing but discipline: enable your backup app’s integrity check and do a quick monthly test restore. The whole thing runs for a few dollars a month plus a one-time drive purchase.
Does RAID Count as One of My Backup Copies?
No. RAID protects against a single drive failing within one device, but it is not a backup, because it does not protect against accidental deletion, ransomware, file corruption, theft, fire, or the failure of the array itself. Ransomware encrypts a RAID volume just as easily as a single disk. Treat RAID as availability for your primary copy, and still keep three real, independent backup copies on top of it.
How Often Should I Test My Backups?
Run automated integrity verification after every backup job so corruption is caught immediately. Do a manual spot-restore of several files monthly to confirm the data is current and openable, and perform a full recovery drill at least once or twice a year, timing it to learn your true recovery window. Testing the restore from your immutable or air-gapped copy is especially important, since that is the copy you will rely on during an actual ransomware event.
Do Cloud and SaaS Apps Like Microsoft 365 or Google Workspace Need Their Own Backup?
Yes. Providers guarantee infrastructure uptime, not protection against your own deletions, retention-policy gaps, or a ransomware-driven mass deletion synced from a compromised account. Most operate a shared-responsibility model where your data is your job to back up. Apply the same 3-2-1-1-0 thinking with a dedicated third-party backup of your SaaS data so a deleted mailbox or corrupted shared drive is recoverable.
