The 3-2-1-1-0 Backup Rule: How to Actually Implement It

The 3-2-1-1-0 Backup Rule: How to Actually Implement It

Attackers go after backups. Veeam’s blog on its 2024 Ransomware Trends Report says “bad actors are targeting backup repositories in 96% of attacks.” Sophos’s March 2024 study of 2,974 IT and cybersecurity professionals at ransomware victims found that 94% said attackers tried to compromise their backups, and that median recovery costs where backups were compromised ($3M) “came in eight times higher” than where they were not ($375K). That gap is the entire argument for the 3-2-1-1-0 backup rule. The old 3-2-1 rule assumed your backups fail by accident. The two new digits assume they fail because someone with domain admin credentials wanted them to.

This guide maps each digit to a real 2026 implementation, not the whiteboard version. The extension is Veeam’s: “It adds one immutable copy, and results in zero recovery errors.” In short: the “+1” means an immutable copy an attacker cannot alter even with your credentials, the “0” means recovery you have actually verified, and immutability is not the same thing as an air gap, however often the two are conflated.

What the digits actually require

Requirement2026 implementation
3Three copies of the dataProduction + primary backup + a copy job to a second target
2Two different media or platformsDisk repository plus object storage, tape, or a different failure domain, not two LUNs on one array
1One copy offsiteCloud object storage, a second data center, or a managed vault
+1One copy immutable or air-gappedS3 Object Lock in compliance mode, a hardened appliance, or offline tape
0Zero errors on verified recoveryAutomated restore testing: Veeam SureBackup, Rubrik Recovery Simulation, or scripted sandbox restores

The takeaway for the meeting: 3-2-1 protects you from hardware and human error; the +1 protects you from an attacker; the 0 protects you from your own untested assumptions. Having the first three digits without the last two leaves the attacker scenario uncovered.

3-2-1: the part you probably already do

Three copies, two media, one offsite is long-standing advice. Data Backup Options, a 2012 paper produced for US-CERT and published by CISA, says: “Keep 3 copies of any important file: 1 primary and 2 backups,” keep them on two media types, and store one copy offsite. Two honest checks are still worth running. First, “two media” should mean two failure domains in practice: a backup repository sitting on the same SAN as production, or in the same vSphere cluster, is one ransomware event away from being zero copies. Second, “offsite” must mean a separate administrative domain, not just separate geography. A DR site joined to the same Active Directory forest with the same admin credentials fails exactly when you need it. If your offsite copy can be deleted from the same console that manages production backups, you have distance, not separation.

The +1: immutable is not air-gapped

Veeam’s own best practice guide writes the “+1” as a choice, “One Copy Offline, Air-gapped, or Immutable,” which makes the terms sound interchangeable. They are different controls with different failure modes, and a mature program eventually wants both.

Immutability is a software or firmware guarantee that written data cannot be modified or deleted for a retention window. S3 Object Lock in compliance mode is the reference example: AWS says a locked object version “can’t be overwritten or deleted by any user, including the root user in your AWS account.” It is online, fast to restore from, and cheap to operate. Its weakness is that it is only as strong as the platform enforcing it: governance-mode locks that users with “special permissions” can lift, retention windows that expire before anyone notices the compromise, or a storage admin account that can destroy the bucket’s account-level container. Compliance mode, MFA on the storage plane, and retention at least as long as your threat-hunting lookback are the minimum bar.

An air gap is a network or physical separation: offline tape, removable media, or storage that is only reachable during controlled windows. It survives platform compromise entirely, but restores are slow, testing is awkward, and “logical air gaps” that amount to a firewall rule deserve skepticism. CISA’s #StopRansomware Guide asks for “offline, encrypted backups of critical data.” Verdict: run immutable object storage as your working +1, and add a true offline copy for the crown-jewel data where a multi-week outage is existential. If you can restore from it in minutes, it is not an air gap, and that is fine, as long as you stop calling it one.

Building the immutable copy: Veeam, Object First, Wasabi, Rubrik

Four approaches cover most mid-market and enterprise deployments. They are not interchangeable.

Veeam: assemble the stack yourself

Veeam Data Platform gives you three routes to the +1: a Linux hardened repository, where backup files “cannot be moved, modified or deleted” during the immutability period; object storage locked with Object Lock and versioning on Amazon S3, S3-compatible storage, Wasabi and others; and Veeam Data Cloud Vault, managed storage that Veeam says is “always immutable” with “flat, per-TB pricing across three editions, including API calls, restore, and egress costs” (the entry Foundation edition lists “fair use restore”). SureBackup covers the 0 by booting workloads from backup in an isolated virtual lab and running verification tests. Strengths: flexibility and a wide choice of storage targets. The honest downside is that Veeam sells you the software and the responsibility: a self-built hardened repo is only hardened if your team locks down SSH, patches the box, and keeps it off the domain. The 96% figure above comes from Veeam’s own research; the company is clear-eyed that its customers’ repositories are the target.

Object First: turnkey on-prem immutability for Veeam shops

Object First’s Ootbi appliance exists to remove that operational burden. Object First describes it as “absolutely immutable” S3 storage on a “Hardened appliance with Zero Access to perform destructive actions to the firmware, OS or data.” As of October 2026, it lists 18 to 432 TB per node, up to 1.7 PB usable in a four-node cluster, and ingest of 1 to 2 GB/s per node depending on model and up to 8 GB/s per cluster, and it is designed for Veeam Instant Recovery, so it can serve as the primary backup target, not just a copy tier. The fit is narrow and deliberate: Object First calls Ootbi “purpose-built for Veeam.” If you run Commvault or Rubrik alongside, plan other immutable storage for those workloads, and weigh the appliance cost against a hardened repository on commodity hardware. For a Veeam shop that wants on-prem immutability without a hardening project, it is the shortest path.

Wasabi: the cheap immutable offsite tier

Wasabi’s pitch is economic: hot cloud object storage with Object Lock support, “Object Storage with Immutability status in the Veeam Ready Program” according to its Veeam integration docs, flat per-terabyte list pricing, and “No fees for egress or API requests,” which matters the day you run a large restore (its FAQ says the policy doesn’t fit if “monthly egress data transfer is greater than your active storage volume”). It covers the “1 offsite” and “+1 immutable” digits in a single move. The limits: Wasabi is storage only, so restore speed is bounded by your internet pipe, and its minimum storage duration (90 days on Pay as You Go, per the same FAQ) means churny short-retention jobs cost more than the headline rate suggests. Model your restore-time math before you rely on it as the only immutable copy; the backup storage cost-per-TB analysis runs those numbers across the major targets.

Rubrik: immutability as architecture

Rubrik takes the opposite approach from the assemble-it-yourself model. It describes an “air-gapped, immutable file system” built into the platform, so immutability is part of the design rather than a setting to get right. Rubrik Security Cloud layers on anomaly detection, threat hunting across “the history of data,” and Recovery Simulation for “creating, testing and validating your cyber recovery plans in isolated environments,” effectively bundling the +1 and the 0 into the platform. The trade-offs are real: it is a platform replacement rather than a bolt-on, and you are committing to one vendor’s stack for backup, immutability and security analytics together, so get pricing in writing before you compare it with assembled options. For organizations that want the rule enforced by architecture rather than by process discipline, that bundle is exactly the point.

For a deeper side-by-side of these targets, including hardened repos, tape and the hyperscaler options, see the immutable backup storage comparison.

The 0: verified recovery, not green checkmarks

A successful backup job proves data was written. It proves nothing about whether the application boots, the database mounts, or the restore completes inside your RTO. The 0 digit demands automated, scheduled verification: Veeam SureBackup boots machines from backup in an isolated virtual lab and runs heartbeat, ping and application tests on a schedule; Rubrik and others offer recovery simulation and clean-room workflows. A starting point (Enterprise Techie’s suggestion, not a published benchmark): every tier-1 workload restore-tested at least quarterly, automated verification running at least weekly (nightly for tier 1), and at least one full DR exercise a year that the infrastructure team does not schedule themselves. CISA’s CPG 2.0 sets a lower floor: “Test backups and recovery on a recurring basis, no less than once per year.” If your last full restore test predates your last major hire, you do not have a 0; you have a hope. Regulated shops should map this cadence to their obligations; the DR testing cadence guide for DORA covers what the regulation requires in writing.

What to do about it

  • This month: inventory which digits you actually have. Check every immutability setting: compliance mode or it does not count. Verify the backup platform has its own identity plane, separate credentials, MFA everywhere.
  • This quarter: stand up one genuinely immutable copy (an Object Lock bucket, an Ootbi node, a hardened repo or a managed vault) and set retention by time, long enough to reach a restore point from before the compromise began. The UK NCSC’s backup principles say to “Store backup data according to a fixed time period, rather than a fixed number of backups,” and NIST SP 800-209 notes that “it often takes a while to notice that a compromise has occurred.” A lock window shorter than your threat-hunting lookback can expire first.
  • This half: automate recovery verification for tier-1 workloads and put the results in front of leadership monthly. The 0 is a reporting artifact as much as a technical one.
  • Ongoing: add an offline or truly isolated copy for existential data, and rehearse restoring from it once a year.

The rule is cheap insurance against an expensive and likely event. Attackers already treat your backups as a target, as the Veeam and Sophos figures above show; 3-2-1-1-0 is simply the posture that assumes they will.

Frequently asked questions

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

Keep three copies of your data on two different media with one copy offsite, plus one copy that is immutable or air-gapped, and verify recovery with zero errors. The last two digits are Veeam’s extension of the classic 3-2-1 rule, aimed at ransomware; CISA warns that “many ransomware variants attempt to find and subsequently delete or encrypt accessible backups.”

Is an immutable backup the same as an air-gapped backup?

No. Immutability is a software guarantee that data cannot be changed or deleted during a retention window; an air gap is physical or network isolation. Immutable storage is online and fast to restore from but depends on the platform enforcing it. An air gap survives platform compromise but restores slowly. Mature programs use immutable storage as the working copy and reserve a true offline copy for critical data.

Does the 3-2-1 rule still apply in the cloud?

Yes, and SaaS data counts too. A cloud workload backed up to the same cloud account is one compromised credential away from total loss. Cross-account or cross-provider copies on immutable storage, for example Veeam writing to an Object Lock bucket on Wasabi or to Veeam Data Cloud Vault, satisfy the offsite and immutable digits without a second data center.

How often should backups be tested?

As a starting point (Enterprise Techie’s suggestion): automated verification at least weekly (nightly for tier-1 workloads), tier-1 restore tests at least quarterly, and a full DR exercise annually; CISA’s floor is “no less than once per year.” Veeam SureBackup or Rubrik’s Recovery Simulation make that practical by testing recovery in an isolated environment.

Enterprise Techie sends vendor-honest analysis like this once a week: get the brief by email, free.

Buying? Start from RFPhub’s free Backup Software RFP template.