The 3-2-1 backup rule in 2026: what each number must prove

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Most backup proposals mention the 3-2-1 rule. Fewer show how each number is met, and almost none explain what the rule leaves out. For a business buyer, that matters: a design can satisfy 3-2-1 on paper and still lose every copy in a single ransomware attack.

This guide is for owners and managers who are reviewing a backup design or a provider's proposal. It explains what 3-2-1 says, where it came from, what current Australian Government guidance adds, and how to check each claim without changing anything.

Where the rule came from

The conventional count is the original data plus two backup copies, making three in total. The traditional rule also calls for two different storage/media types and at least one off-site copy. The Texas State Library and Archives Commission states: "keep three complete copies of your information, two of the copies should be on varied media, and one copy should be stored off-site."

It traces the government recommendation to 2012: "In 2012, the National Cybersecurity and Communications Integration Center (NCCIC) gave its recommendation for the 3-2-1 Backup Rule in a paper titled Data Backup Options." That paper is now hosted by the US Cybersecurity and Infrastructure Security Agency; it refused automated access, so this guide does not quote it directly.

The Texas post also explains the off-site copy's role: "This is the final line of defense in case of a catastrophic physical and technological failure." And it adds a cost caution worth keeping: applying the rule to everything "can become costly and unnecessary if you are maintaining 3 copies of convenience or transitory information".

What each number protects against

In our reading, each part of the rule answers a different failure:

• Three copies: the original plus two complete backups can leave alternatives if one copy fails; job success and recovery checks still need to establish usable copies.
• Two media/storage types: document the actual formats or technologies used for the traditional diversity condition. Different provider names alone do not prove different media. Separately assess whether hardware, software, site or account failures could reach multiple copies.
• One off-site: fire, flood or theft at one site does not take every copy.

These are all accidents or physical events. The rule was not designed around an intruder who has the passwords (our reading).

What 3-2-1 does not say

Four gaps matter most today, in our reading.

1. Who can delete the copies. If one administrator account can reach all three, an attacker with that account can delete all three.
2. Whether copies can be changed during their retention. A copy that can be overwritten is not a safe copy.
3. Whether anyone has restored from them. A copy nobody has tested is an assumption.
4. Whether the copies line up. Copies of related systems taken at different times may not restore into a working whole.

Australian Government guidance addresses each of these.

What the Essential Eight adds

The Australian Signals Directorate's Essential Eight includes "Regular backups". At maturity level one its requirements include:

• "Backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements."
• "Backups of data, applications and settings are synchronised to enable restoration to a common point in time."
• "Backups of data, applications and settings are retained in a secure and resilient manner."
• "Restoration of data, applications and settings from backups to a common point in time is tested as part of disaster recovery exercises."
• "Unprivileged user accounts are prevented from modifying and deleting backups."

The higher levels restrict privileged accounts further. At maturity level three: "Backup administrator accounts are prevented from modifying and deleting backups during their retention period."

ASD's assessment guide explains why ordinary accounts matter: "This requirement exists as ransomware running with the privileges of an unprivileged user should be blocked from overwriting or deleting backups." On testing, it says restoration should "be tested as part of regular (at least annually) disaster recovery exercises and not left until after the first major security incident is experienced."

What the ISM adds

ASD's Information Security Manual, in its Guidelines for system management, includes two backup controls marked as updated in September 2026 and not mapped to the Essential Eight:

• ISM-2151: "Backups are stored using a technically enforced immutability mechanism that prevents their modification or deletion for the duration of their retention period."
• ISM-2152: "Backup infrastructure, including backup servers, repositories and management consoles, is segregated from production environments and uses a separate authentication mechanism for administrative access."

The ISM gives the reason for the second: "as malicious actors routinely seek to access backup infrastructure using credentials harvested from production environments, backup infrastructure should be segregated from such environments and use a separate authentication mechanism for administrative access."

The ISM is a government cybersecurity framework that private businesses can also use as a reference. The Essential Eight addresses organisations' internet-connected IT networks, including businesses and government agencies. Whether particular controls are binding depends on applicable government policy, regulation or contracts; assess that separately from choosing risk-based improvements.

What NIST adds

NIST SP 800-209, a US guide to storage security, treats backup protection in more detail. It lists protection requirements including "immutability and locking, minimum number of copies per backup set, and the geographic distribution of such copies." It defines immutability as "the ability to lock data after it has been created, thereby preventing it from alteration or deletion."

On separation, it recommends that "Long-term archive and backup systems should be separated from production data storage systems." And it suggests recovery copies "should not be mounted, exported, or mapped to a host or application, and they should be restored (pushed) onto an isolated staging (or air-gapped) environment rather than directly onto the target hosts or applications."

NIST is also measured about how far to go. On keeping separate copies purely for recovery from attack, it says the practice, "while recommended for critical and sensitive systems, is not mandatory." In our reading, that supports matching the strength of protection to how critical each system is, rather than applying the strictest design everywhere.

Copies that are not really copies

Some things counted as copies do not behave like backups (our reading):

• Sync and replication. A folder synchronised to the cloud, or a database replicated to a second server, usually copies deletions and encryption too. It protects against hardware failure, not against a mistake or an attack that is copied across within minutes.
• Snapshots on the same storage. A snapshot kept on the same storage system as the original shares that system's faults and, often, its administrator accounts.
• A second disk in the same box. Two disks in one appliance are two media in one place, with one set of controls.

Each can be a useful layer. None should be counted as an independent copy without checking how deletion, corruption and access reach it.

A 2026 reading of 3-2-1

Putting these together, a buyer can ask each number to prove something (our recommendation):

Vendors sometimes describe extended versions of the rule with extra digits for an immutable or offline copy and for tested restores (our understanding). The names vary; the questions above matter more than the label.

Read-only checks

These checks read settings and records; they change nothing. They are reviews of your backup system's console, reports or provider documents rather than commands.

1. Count the copies. For one important system, identify the original and two backup copies. Record location, actual media/storage type, update frequency and dependencies for each. Mark any diversity or failure-separation claim that remains unverified.
2. Check job history. Look at the last 30 days of jobs for each copy. Note any failures and whether anyone was told.
3. List who can delete. For each copy, list the accounts that can delete or shorten its retention, including provider staff.
4. Check for a separate sign-in. Confirm whether backup systems use the same sign-in as everyday administration.
5. Check lock settings. Record whether each copy has a retention lock or immutability setting and who can change it.
6. Find the last restore test. Note its date, what was restored, and whether related systems were restored to the same point.

These checks show the design on paper. Only a restore proves the copies work (our recommendation).

Safe restore rehearsal

1. Choose one system and the copy you trust least, often the off-site one.
2. Restore it to an isolated test environment with no connection to production.
3. Check that the data opens, that its date is what you expected, and that related systems restored to the same point.
4. Time the whole process and compare with your recovery time objective.
5. Record the result and repeat with a different copy next time.

Diagnosing what you find

• Only two real copies exist: the "copy" is a sync or replica that would copy deletion too; a job has been failing silently; or one copy is on the same storage as the original.
• One account can delete everything: backup systems share the main administrator sign-in; the provider holds full rights; or lock settings were never turned on.
• The off-site copy will not restore: it was never tested; its keys are held only on-site; or the transfer has been incomplete.
• Related systems do not line up: copies run at different times; dependencies were not listed; or only some systems are backed up.

Worked example (illustrative)

In this invented review, a firm identifies the original data, a local appliance backup and an off-site cloud backup. A second disk in the appliance is an additional component, not proof of another independent recovery path. The team documents actual media/storage technologies; if diversity cannot be established, that condition remains unverified even though the providers differ. It separately identifies shared appliance faults and a production administrator able to delete the cloud copy. After authorised access-separation and retention-lock changes, a hypothetical isolated restore of the named system from the off-site set matches its recorded recovery-point fixture and application checks. That outcome covers only the tested set and system; it neither proves every copy nor resolves any outstanding media-diversity evidence. No author-run test is claimed.

Risks and limits

• The original NCCIC paper was not read directly; its wording here comes from a secondary government source.
• Essential Eight guidance addresses businesses as well as government organisations. Determine applicable policy, legal or contractual duties separately, and adapt controls to the system and risk.
• No copy count replaces a tested restore.
• Control numbers and wording change; check the current ISM release before citing it in a contract.

Sources

All accessed 14 November 2026.

• ASD, Essential Eight maturity model: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model
• ASD, Essential Eight assessment process guide: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-assessment-process-guide
• ASD, ISM Guidelines for system management: https://cyber.gov.au/business-government/asds-cyber-security-frameworks/ism/cyber-security-guidelines/guidelines-for-system-management
• NIST, SP 800-209, Security Guidelines for Storage Infrastructure (October 2020): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
• Texas State Library and Archives Commission, 3-2-1 Backup Rule (2018, modified 2025): https://www.tsl.texas.gov/slrm/blog/2018/11/3-2-1-backup-rule/

Related future topics

• Logical and physical air gaps for backup repositories
• Separate sign-in for backup systems
• Restoring related systems to a common point in time

This article was originally published on 14 November 2026.