The 3-2-1-1-0 Backup Strategy and Immutable Backups

A backup is a copy of your data kept somewhere else so you can restore it when the original is damaged, and it has to survive ransomware, which is malware that encrypts data until a ransom is paid. The 3-2-1-1-0 rule is an easy-to-remember guide to how many copies to keep, where to keep them and how to check them. An immutable backup is a copy that is locked and cannot be changed or deleted until a set time has passed, so at least one copy survives even after an attacker is inside the network. This article explains how to build a 3-2-1-1-0 backup with immutable copies step by step, and separates what NIST and CISA recommend from what is industry convention.

Why an ordinary backup is not enough against ransomware

CISA, the US cybersecurity agency, says many ransomware variants try to find backups they can reach and delete or encrypt them, which makes restoration impossible unless the ransom is paid. In a 2019 blog post, the UK's NCSC reported incidents where ransomware encrypted the original data and also the connected USB drives, network drives and cloud storage that held backups.

NIST SP 800-209, the storage security guideline, spells out the consequence: if attackers can also compromise the backup copies, an attack on production is devastating because the organization cannot recover. It therefore separates two cases. The first is recovery from non-malicious events such as hardware failure or accidental deletion. The second is recovery after a cyber attack, which needs copies that are hardened, locked and kept in isolation, so they stay unaffected even when production has been compromised.

The 3-2-1 rule is the first item in How to Prevent Ransomware: 5 First Steps for Organizations. This article takes that item further.

The 3-2-1-1-0 rule: what each number means

The rule has five numbers, as commonly described by backup vendors and IT media:

• 3 copies: keep at least three copies of the data. Veeam counts the original, so that means the original plus at least two backups
• 2 media types: store them on different kinds of storage, for example on-premises disk and cloud, or tape, so one kind of storage failure does not take out every copy
• 1 copy off-site: kept away from the location of the live systems, so it survives an event there such as a fire or flood
• 1 copy attackers cannot change or delete (the last 1): an offline copy (disconnected), an air-gapped copy (separated from the network) or an immutable copy (locked against changes). Sources differ on which
• 0 errors: check and test restores regularly until you are sure they work, rather than trusting that the backup job reported success

The definitions are not identical across sources. Veeam, a backup software vendor, counts the three copies including the original. A TechTarget article (an IT news site, January 2026) counts three backups in addition to the original, which makes four copies in total. Veeam describes the last 1 as immutable or air-gapped, while TechTarget describes it as offline. So if you write this rule into an internal policy, state clearly whether the three copies include the original and what the last 1 means.

The last 1 relates to a gap in the original rule. The NCSC pointed out that 3-2-1 does not require any backup location to be offline, and so recommends an extra offline rule: keep at least one backup offline at any given time and never have all backups connected at once, so that a single incident cannot reach every copy.

Be clear about the status of this rule. The 3-2-1 rule is not a mandatory standard, although CISA calls it a "trusted guideline" on its Back Up Government Data page. The 3-2-1-1-0 rule is an industry convention published by software vendors and IT media, not a standard. We did not find the name 3-2-1-1-0 in the CISA and NIST documents checked for this article. Those documents recommend the same principles in other words, such as offline copies, lockable copies and restore testing. Use the rule as a checklist, and do not present it as a criterion for compliance with a standard.

How immutable backup works

NIST SP 800-209 defines immutability as the ability to lock data after it has been created so that it cannot be altered or deleted. In practice, several object storage systems (storage that keeps data as objects, often used in the cloud) offer this, for example Amazon S3 Object Lock and Azure Blob Storage immutable storage. Both use the WORM model (write once, read many). An administrator sets a retention period, and until it ends the data cannot be changed or deleted.

Besides locking inside the storage system, there are other ways to keep copies out of an attacker's reach:

• Offline: do not connect the copy to live systems when it is not in use, for example tape or a disk that is removed and stored. The NCSC recommends keeping at least one copy offline at all times. For cloud storage that cannot be unplugged, disconnect it by configuration, for example by making sure the backup client holds no valid credentials when it is not in use
• Air gap: NIST describes two kinds. The strict kind means full physical and network-level separation. The less strict kind keeps data ports shut and opens them for a limited time for a periodic sync. Choose based on the value of the data and the capabilities of the adversary
• Separate accounts and management: in a public cloud, NIST says to keep recovery copies in separate accounts and manage them from systems separate from production, which regular production or backup credentials cannot access
• Restrict who can reach it: for sensitive data, NIST says to give access to a single person or a very narrow group, for example the CISO (chief information security officer), using credentials separate from day-to-day duties, so that a compromised IT administrator account cannot reach the recovery copies

S3 Object Lock has two modes that differ a lot. In compliance mode, no user can overwrite or delete a protected object version, including the root user of the AWS account, and the retention period cannot be shortened. In governance mode, users who hold a special permission can still bypass the lock, so that permission must be protected as carefully as the copy itself.

Limits to know before relying on immutable backup:

• Locking bad data locks it too: immutability prevents changes after writing, but it does not say whether the data was clean when written. CISA warns to look for dropper malware before restoring from backups so systems are not reinfected
• Hard to undo if set wrongly: CISA advises caution because misconfiguration can impose significant cost, and AWS states that compliance mode retention cannot be shortened. AWS suggests using governance mode to test retention settings first
• May conflict with some regulations: CISA says immutable storage does not meet the compliance criteria of certain regulations, so check with legal or compliance staff before choosing a lock period
• Each file version is locked separately: S3 Object Lock requires versioning (keeping several versions of a file) and does not stop new versions or delete markers from being added, but the earlier locked version remains intact
• The backup management account still needs protection: if one account administers both production and backup, an attacker who steals it might switch off backup jobs or change settings. See PAM Explained: Controlling Privileged Access

Building it step by step

The order below is our own arrangement of CISA and NIST guidance, not a sequence prescribed by any one document:

• Identify the data and systems you cannot do without: CISA starts with an inventory of important data and then prioritizing what to protect
• Set recovery targets: define an RPO (how much data loss, measured in time, you can accept) and an RTO (the longest time recovery may take) for each system. How to set them, with a worked calculation, is in Ransomware Recovery Plan: RTO, RPO and Rehearsals
• Get 3-2-1 right first: an on-site copy, an off-site copy and at least two kinds of media, running automatically and regularly, as CISA recommends
• Add a copy attackers cannot delete: choose immutable, offline or air-gapped, at least one of them, according to budget and the importance of the data
• Separate privileges and enable MFA: accounts that manage backups use MFA (multi-factor authentication) and are separate from day-to-day accounts
• Back up the whole system, not only data files: NIST includes certificates, encryption keys and configuration files, as well as Active Directory (the system that manages the organization's user accounts) and DNS (the system that maps domain names to machines), because they are needed to restore systems completely. CISA recommends keeping golden images (preconfigured system templates ready to redeploy) of critical systems
• Watch for tampering with backups: alert when backups are deleted or jobs are switched off. CISA says to look for misuse of Windows tools that attackers use to destroy shadow copies (older versions that Windows keeps), such as vssadmin.exe and wbadmin.exe

Restore testing: earning the 0

The 0 means backups that can actually be restored, not just backup jobs that finished. NIST SP 800-209 notes that many organizations have backups but do not regularly check that they can restore from them, and find out only after an incident that they cannot. NIST says to test restores periodically, to restore into an isolated environment rather than directly over production, and to scan the restored copies with anti-malware tools. It also says to check that copies are in good health at least once a year, more often for important systems. CISA recommends testing both full and partial restores, and making sure you can roll data back at least seven days.

Common mistakes

• Treating 3-2-1 as enough against ransomware: the NCSC points out that it does not require any offline copy, so all three copies may stay connected to the same network and be encrypted together
• Keeping the "off-site" copy in the same cloud account as production: if the account is taken over, every copy goes with it. NIST says to use separate accounts, and CISA suggests considering several clouds to avoid depending on one provider
• Letting one administrator hold privileges over both production and backup: steal that one account and the attacker gets both
• Setting a long lock period without testing first: in compliance mode a wrong setting cannot be shortened, and you pay to store the data for the whole lock
• Counting a backup as done when the job shows success: nobody has ever tried a restore, so nobody knows whether it works
• Forgetting to back up what is needed to restore: for example encryption keys, Active Directory, DNS and software licensing records, which NIST and CISA say to keep too
• Handing backups to a provider without contract terms: CISA says to put security requirements in the contract with the managed service provider (MSP) that looks after backups

Start today

• Answer three questions for one critical system: how many copies exist, where are they, and which one can administrators not delete
• Check who can delete backups or switch off backup jobs: and whether those accounts use MFA yet
• Try restoring one critical system: restore into a test area, time it and write down the result
• Try locking data in a test account: use governance mode or the equivalent lock feature of your platform to see how it behaves before using it for real
• Write down how your organization reads the 3-2-1-1-0 rule: how it counts the three copies and what the second 1 means
• Alert on backup deletions: send the alert to a team other than the backup administrators themselves

To see where your organization's backup and recovery stand, try the self-assessment.

References and further reading

• CISA #StopRansomware Guide: advice on offline backups, restore testing, immutable storage and backups run by providers
• CISA Back Up Government Data: the 3-2-1 rule as a trusted guideline, and the seven-day rollback test
• NIST SP 800-209: Security Guidelines for Storage Infrastructure: recommendations on isolating recovery copies, immutability, air gaps and checking that restores work
• NIST SP 1800-11: Data Integrity: Recovering from Ransomware and Other Destructive Events: practice guide and example systems for data recovery
• NCSC: Offline backups in an online world: the reasoning behind the offline rule and how to separate cloud backups from live systems
• AWS: Locking objects with Object Lock: compliance and governance modes of S3 Object Lock
• Microsoft: Immutable storage for Azure Blob Storage: time-based retention policies and legal holds
• Veeam: 3-2-1 Backup Rule: a vendor definition that uses the name 3-2-1-1-0
• TechTarget: Use the 3-2-1-1-0 rule for better backups: an IT media explanation that counts copies differently from Veeam