--- title: "The 3-2-1-1-0 Backup Rule Explained: Origin, Meaning and Pr…" description: "An independent explainer on the 3-2-1-1-0 backup rule: its origin in the classic 3-2-1 rule, what the offline copy and zero errors requirement mean, how each…" lang: en-GB json-ld: | [ { "@context": "https://schema.org", "@type": "Organization", "@id": "https://fire-vault.com/#organization", "name": "Firevault", "legalName": "Firevault Limited", "url": "https://fire-vault.com", "logo": { "@type": "ImageObject", "url": "https://fire-vault.com/logo.png", "width": 200, "height": 60 }, "foundingDate": "2025-03", "description": "Protect what matters with Offline Secure Storage and control what moves with Control by Firevault. Physically disconnected, always reachable by you.", "address": { "@type": "PostalAddress", "addressCountry": "GB", "addressLocality": "United Kingdom" }, "contactPoint": [ { "@type": "ContactPoint", "contactType": "customer service", "email": "hello@fire-vault.com", "availableLanguage": "English", "areaServed": [ "GB", "EU", "US", "AE" ] } ], "sameAs": [ "https://www.linkedin.com/company/firevault", "https://x.com/firevaultuk" ], "slogan": "Disconnect to Protect", "knowsAbout": [ "Offline Secure Storage", "Physical Air Gap Data Protection", "Ransomware Protection", "Data Sovereignty", "GDPR Compliance", "NIS2 Compliance" ] }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://fire-vault.com/#website", "name": "Firevault", "alternateName": [ "Firevault", "Firevault UK", "Firevault Limited" ], "url": "https://fire-vault.com", "publisher": { "@id": "https://fire-vault.com/#organization" }, "inLanguage": "en-GB", "description": "Protect what matters with Offline Secure Storage and control what moves with Control by Firevault. Physically disconnected, always reachable by you.", "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://fire-vault.com/learn?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@context": "https://schema.org", "@type": "WebPage", "@id": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule#webpage", "url": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule", "name": "The 3-2-1-1-0 Backup Rule Explained: Origin, Meaning and Pr…", "description": "An independent explainer on the 3-2-1-1-0 backup rule: its origin in the classic 3-2-1 rule, what the offline copy and zero errors requirement mean, how each…", "isPartOf": { "@id": "https://fire-vault.com/#website" }, "about": { "@id": "https://fire-vault.com/#organization" }, "primaryImageOfPage": { "@type": "ImageObject", "url": "https://fire-vault.com/images/og/og-base-learn.jpg" }, "inLanguage": "en-GB", "breadcrumb": { "@id": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule#breadcrumb" } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "@id": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://fire-vault.com" }, { "@type": "ListItem", "position": 2, "name": "Home", "item": "https://fire-vault.com/" }, { "@type": "ListItem", "position": 3, "name": "Knowledge Vault", "item": "https://fire-vault.com/learn/knowledge" }, { "@type": "ListItem", "position": 4, "name": "The 3-2-1-1-0 Backup Rule Explained", "item": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule" } ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "The 3-2-1-1-0 Backup Rule Explained: Origin, Meaning and Pr…", "description": "An independent explainer on the 3-2-1-1-0 backup rule: its origin in the classic 3-2-1 rule, what the offline copy and zero errors requirement mean, how each…", "image": "https://fire-vault.com/images/og/og-base-learn.jpg", "author": { "@type": "Organization", "name": "Firevault" }, "publisher": { "@type": "Organization", "name": "Firevault", "logo": { "@type": "ImageObject", "url": "https://fire-vault.com/logo.png" } }, "datePublished": "2025-11-25", "dateModified": "2026-08-27", "mainEntityOfPage": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule" }, { "@context": "https://schema.org", "@type": "TechArticle", "@id": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule#article", "headline": "The 3-2-1-1-0 Backup Rule Explained", "description": "An independent explainer on the 3-2-1-1-0 backup rule: its origin in the classic 3-2-1 rule, what the offline copy and zero errors requirement mean, how each digit fails, and how to evidence it to an auditor or insurer.", "about": [ { "@type": "Thing", "name": "3-2-1 backup rule" }, { "@type": "Thing", "name": "3-2-1-1-0 backup rule" }, { "@type": "Thing", "name": "Offline backup" }, { "@type": "Thing", "name": "Immutable backup" }, { "@type": "Thing", "name": "Backup verification" } ], "keywords": "3-2-1-1-0 backup rule, 3-2-1 backup rule, offline backup copy, immutable backup, air gapped backup, backup verification, test restore, cyber insurance backup requirements, ransomware resilient backup, backup audit evidence", "articleSection": "Backup and recovery", "inLanguage": "en-GB", "isAccessibleForFree": true, "wordCount": 2400, "image": [ "https://fire-vault.com/assets/explainer-3-2-1-1-0-backup-rule-DYRpJOeu.jpg" ], "author": { "@type": "Person", "name": "Mark Fermor", "url": "https://fire-vault.com/about", "jobTitle": "Director and Co-Founder, Firevault" }, "publisher": { "@type": "Organization", "name": "Firevault", "url": "https://fire-vault.com" }, "datePublished": "2025-11-25", "dateModified": "2026-08-27", "url": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://fire-vault.com/learn/3-2-1-1-0-backup-rule" }, "citation": [ { "@type": "CreativeWork", "name": "CISA and MS-ISAC, Ransomware Guide (StopRansomware.gov)", "url": "https://www.cisa.gov/stopransomware/ransomware-guide" }, { "@type": "CreativeWork", "name": "NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events", "url": "https://www.nccoe.nist.gov/projects/data-integrity-recovering-ransomware-and-other-destructive-events" }, { "@type": "CreativeWork", "name": "NIST Cybersecurity Framework 2.0, Recover function", "url": "https://www.nist.gov/cyfr/framework" }, { "@type": "CreativeWork", "name": "NCSC UK, Offline backups in an online world", "url": "https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world" }, { "@type": "CreativeWork", "name": "NCSC UK, Mitigating malware and ransomware attacks", "url": "https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is the 3-2-1-1-0 backup rule?", "acceptedAnswer": { "@type": "Answer", "text": "It is an extension of the classic 3-2-1 backup rule for the ransomware era. Keep three copies of your data, on two different types of media, with at least one copy offsite, plus one copy offline, and zero errors confirmed on recovery through regular test restores." } }, { "@type": "Question", "name": "Where did the 3-2-1 backup rule come from?", "acceptedAnswer": { "@type": "Answer", "text": "The 3-2-1 rule predates modern ransomware and originates from general data protection and disaster recovery practice, commonly attributed to photographer and author Peter Krogh in the context of protecting irreplaceable digital files, later adopted broadly across IT and backup vendor guidance as a simple, memorable resilience standard." } }, { "@type": "Question", "name": "Why was one offline copy added to the rule?", "acceptedAnswer": { "@type": "Answer", "text": "Because modern ransomware operators deliberately search for and encrypt or delete reachable backup systems before deploying the main attack. A copy with no active network connection cannot be reached by that step, regardless of which credentials the attacker has compromised, which is why guidance including NCSC UK's recommends an offline or air-gapped copy specifically." } }, { "@type": "Question", "name": "What does zero errors mean in 3-2-1-1-0?", "acceptedAnswer": { "@type": "Answer", "text": "It means a copy is only counted as a working backup once it has been restored and verified, not simply once it has been written. The zero refers to the target number of errors found during a genuine test restore, covering data integrity, completeness and the ability to bring systems back into operation within an acceptable time." } }, { "@type": "Question", "name": "Does immutable cloud backup satisfy the offline requirement?", "acceptedAnswer": { "@type": "Answer", "text": "No. Immutable or object-locked cloud backup is a logical, policy-based control on storage that remains reachable over a network and administered through the same identity plane as everything else in that account. The offline requirement in the rule specifically calls for a copy with no network path, which immutability alone does not provide." } }, { "@type": "Question", "name": "How often should test restores be performed?", "acceptedAnswer": { "@type": "Answer", "text": "There is no single universal figure, but guidance from NIST and NCSC consistently emphasises regular, scheduled testing rather than one-off validation. Many organisations align test restore frequency with their recovery time objective review cycle, commonly quarterly for critical systems and at least annually for lower priority data." } }, { "@type": "Question", "name": "How do the two different media in 3-2-1-1-0 help against ransomware?", "acceptedAnswer": { "@type": "Answer", "text": "Different media types, such as disk-based object storage and physically disconnected storage, fail differently and are exploited differently. Malware or an exploit that succeeds against one storage platform or vendor's software stack does not automatically succeed against a different medium, which reduces the chance that a single technique destroys every copy." } }, { "@type": "Question", "name": "What counts as an offsite copy under the rule?", "acceptedAnswer": { "@type": "Answer", "text": "A copy stored at a genuinely separate location from the primary site, with independent power, network and physical access controls, such as a different data centre, a different cloud region, or a dedicated offsite vaulting facility. The intent is that a fire, flood or localised destructive incident at the primary site cannot also destroy the offsite copy." } }, { "@type": "Question", "name": "How do you evidence the 3-2-1-1-0 rule to an auditor or insurer?", "acceptedAnswer": { "@type": "Answer", "text": "Provide documented backup schedules and copy counts, storage media and location records for each copy, logs showing when the offline copy was connected and for what purpose, and dated test restore reports showing what was restored, when, and with what result. Insurers increasingly ask specifically for evidence of a tested offline or air-gapped copy rather than a written policy alone." } }, { "@type": "Question", "name": "What is the most common way the 3-2-1-1-0 rule fails in practice?", "acceptedAnswer": { "@type": "Answer", "text": "The most common failure is treating a rule that should describe five independently verified controls as a single tick-box exercise, most often by assuming immutable cloud storage satisfies the offline requirement, or by never actually testing a restore and only discovering a corrupt or incomplete backup during a real incident." } } ] } ] --- Recent Breaches Breaches [2026 PowerSchool 62.4M records ](/learn/breaches)[2026 DISA Global Solutions 3.3M records ](/learn/breaches)[2026 Globe Life 850K records ](/learn/breaches)[2026 Lidl GB Customer contact data ](/learn/breaches)[2026 Asahi Group Production systems disrupted ](/learn/breaches)[2026 Kido International 8K records ](/learn/breaches)[2026 Collins Aerospace (RTX) Check-in and boarding disruptio... ](/learn/breaches)[2026 Jaguar Land Rover Production and IT systems disru... ](/learn/breaches)[2026 Peter Green Chilled Order and logistics data ](/learn/breaches)[2026 Adidas UK Customer contact details ](/learn/breaches)[2026 PowerSchool 62.4M records ](/learn/breaches)[2026 DISA Global Solutions 3.3M records ](/learn/breaches)[2026 Globe Life 850K records ](/learn/breaches)[2026 Lidl GB Customer contact data ](/learn/breaches)[2026 Asahi Group Production systems disrupted ](/learn/breaches)[2026 Kido International 8K records ](/learn/breaches)[2026 Collins Aerospace (RTX) Check-in and boarding disruptio... ](/learn/breaches)[2026 Jaguar Land Rover Production and IT systems disru... ](/learn/breaches)[2026 Peter Green Chilled Order and logistics data ](/learn/breaches)[2026 Adidas UK Customer contact details ](/learn/breaches) [View All →](/learn/breaches) [![Firevault - offline secure storage, physically disconnected from the internet](/assets/logo-color-DBVl0KCg.png)](/) Products Solutions [Why OSS](/why-oss) More [Help](/help)[Get started](/get-started) [Knowledge Vault](/learn/knowledge) Explainer Backup and recovery # The 3-2-1-1-0 Backup Rule Explained Three copies, two media, one offsite, one offline, zero errors on recovery. This explainer traces the rule back to its 3-2-1 origin, sets out what each added digit actually requires, and how to prove compliance rather than assume it. ![Mark Fermor](/assets/mark-fermor-aWtKNSv7.jpg) Mark Fermor Director & Co-Founder, Firevault 25 November 2025 16 min read Share [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule)[](https://twitter.com/intent/tweet?url=https%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule&text=The%203-2-1-1-0%20Backup%20Rule%20Explained%0A%0AThree%20copies%2C%20two%20media%2C%20one%20offsite%2C%20one%20offline%2C%20zero%20errors%20on%20recovery.%20This%20explainer%20traces%20the%20rule%20back%20to%20its%203-2-1%20origin%2C%20sets%20out%20what%20each%20added%20digit%20actually%20requires%2C%20and%20how%20to%20prove%20compliance%20rather%20than%20assume%20it.)[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule)[](mailto:?subject=The%203-2-1-1-0%20Backup%20Rule%20Explained&body=Three%20copies%2C%20two%20media%2C%20one%20offsite%2C%20one%20offline%2C%20zero%20errors%20on%20recovery.%20This%20explainer%20traces%20the%20rule%20back%20to%20its%203-2-1%20origin%2C%20sets%20out%20what%20each%20added%20digit%20actually%20requires%2C%20and%20how%20to%20prove%20compliance%20rather%20than%20assume%20it.%0A%0Ahttps%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule) ![A data centre backup rack with labelled storage tiers representing the 3-2-1-1-0 backup rule](/assets/explainer-3-2-1-1-0-backup-rule-DYRpJOeu.jpg) The 3-2-1-1-0 rule extends the classic 3-2-1 backup rule with an offline copy and a verified restore requirement, reflecting a threat model where attackers target backup infrastructure directly. Written by Mark Fermor, Co-Founder, Firevault Technical review Firevault architecture team First published 25 November 2025 Last reviewed 27 August 2026 Review cycle At least annually, or following material changes to NIST, NCSC or ISO guidance. How we built this explainer: This explainer traces the origin of the 3-2-1 rule, sets out the additions that produced 3-2-1-1-0, and cites NIST, NCSC and CISA guidance on backup resilience and ransomware recovery. It avoids invented statistics and cites only guidance that is publicly verifiable. **On this page**[The origin of the 3-2-1 rule](#origin)[What each number in 3-2-1-1-0 requires](#numbers)[The added one: an offline, air-gapped or immutable copy](#the-extra-one)[The added zero: verified restores](#the-zero)[How each digit fails in practice](#how-it-fails)[Testing and verification discipline](#testing)[How the rule maps to recognised guidance](#standards)[How to evidence the rule to an auditor or insurer](#evidence)[A practical compliance checklist](#checklist)[Limits of the rule](#limits)[How Firevault applies these principles](#firevault)[The key takeaway](#takeaway)[Sources and further reading](#sources) On this page 1. [The origin of the 3-2-1 rule](#origin) 2. [What each number in 3-2-1-1-0 requires](#numbers) 3. [The added one: an offline, air-gapped or immutable copy](#the-extra-one) 4. [The added zero: verified restores](#the-zero) 5. [How each digit fails in practice](#how-it-fails) 6. [Testing and verification discipline](#testing) 7. [How the rule maps to recognised guidance](#standards) 8. [How to evidence the rule to an auditor or insurer](#evidence) 9. [A practical compliance checklist](#checklist) 10. [Limits of the rule](#limits) 11. [How Firevault applies these principles](#firevault) 12. [The key takeaway](#takeaway) 13. [Sources and further reading](#sources) The 3-2-1-1-0 backup rule is the modern, extended reading of a much older idea. It states that an organisation should keep three copies of important data, on two different types of media, with one copy offsite, plus one copy offline, and zero errors confirmed on recovery. Every clause exists to close a specific failure mode that has actually happened to real organisations. This explainer sets out where the rule came from, what each digit genuinely requires, the ways each one fails when organisations only pay lip service to it, and how to produce evidence that will satisfy an auditor or a cyber insurer rather than only an internal policy document. ## The origin of the 3-2-1 rule The 3-2-1 rule predates cloud computing and ransomware as a named threat. It is widely attributed to photographer and author Peter Krogh, who set it out in the context of protecting irreplaceable digital photography from loss, and it was subsequently adopted broadly across general IT backup practice as a simple, memorable standard: three copies of data, on two different types of media, with one copy kept offsite. The logic was originally about disaster and hardware failure rather than deliberate attack. A single copy can be lost to a failed drive. Two copies on the same medium can both fail to the same defect or the same local disaster. An offsite copy protects against the loss of an entire site to fire, flood or theft. As a baseline against accidental loss, the rule has held up for decades. ## What each number in 3-2-1-1-0 requires The extended rule keeps the original three digits and adds two more that address a threat model the original rule did not anticipate: an adversary who deliberately targets backup infrastructure. 3 COPIES Production plus two independent backups No single storage system holds the only copy of anything important. 2 MEDIA At least two different storage technologies A defect, exploit or vendor failure affecting one medium does not automatically affect the other. 1 OFFSITE A copy at a genuinely separate location Protects against fire, flood, theft or destruction of the primary site. 1 OFFLINE A copy with no active network connection Cannot be reached, altered or deleted by an attacker operating remotely over the network. 0 ERRORS A copy proven restorable through testing Verified end to end, not assumed to work because the backup job reported success. The five requirements of the 3-2-1-1-0 rule, each closing a distinct failure mode. ## The added one: an offline, air-gapped or immutable copy The additional one addresses a specific, observed pattern in ransomware operations: attackers who gain a foothold now routinely search for and attack backup infrastructure before deploying the payload that encrypts production systems, precisely because a working backup removes their leverage. Guidance from [CISA and the MS-ISAC](https://www.cisa.gov/stopransomware/ransomware-guide) and from [NCSC UK](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks) both recommend keeping backups offline, or on a separate network segment that is not continuously reachable, for exactly this reason. ### Offline, air-gapped and immutable are not interchangeable terms These three terms are frequently used as if they meant the same thing. They do not, and the difference matters when deciding whether a given copy actually satisfies the rule. Immutable backup Data cannot be altered or deleted for a set period, enforced by policy on storage that remains network reachable. Air-gapped A general term for storage with no network path, which can be achieved physically or, less reliably, through strict logical isolation. Offline The storage medium has no active network connection while disconnected. This is a physical state, not a configuration setting. Immutable but connected Network Data - Reachable through the provider's console and API - Retention governed by configuration and identity - A sufficiently privileged compromise can still reach it Offline, air-gapped copy Network Data - No network interface active while disconnected - Reconnected only through a scheduled, verified process - Not reachable through any remote credential compromise Only a genuinely offline copy removes the network path an attacker needs to reach it. A copy protected only by immutability settings, however well configured, is still one privileged account compromise, one misconfiguration, or one sufficiently patient attacker away from being at risk. The rule's added one is specifically written to require the stronger guarantee. ## The added zero: verified restores The zero refers to the number of errors an organisation should find when it actually restores from a backup copy. It is a deliberately blunt way of saying that a backup which has never been restored is not a proven backup, it is an assumption. Backup software reporting a job as successful confirms that data was written; it does not confirm that data can be read back, that it is complete, or that dependent systems can actually be brought back into a working state from it. A restore, not a report, is the proof: A green tick in a backup console is evidence that a job ran. It is not evidence that the organisation can recover. Only a scheduled, documented test restore, checked against the original data or a known good state, produces evidence of the zero. ## How each digit fails in practice Each part of the rule has a distinct, observable way it commonly fails when organisations believe they are compliant but are not. 1. Three copies fails. when two of the three copies are actually snapshots or replicas of the same underlying storage system, sharing a single point of failure despite being counted separately. 2. Two media fails. when both media are different products from the same vendor sharing the same management software, so a single exploit or licensing failure affects both. 3. One offsite fails. when the offsite copy is in a different building on the same organisational network, sharing the same identity plane and therefore the same attacker access path. 4. One offline fails. when the offline copy is described as air-gapped but is in fact a logically isolated network segment that a determined attacker with enough time and lateral movement can still reach. 5. Zero errors fails. when test restores are skipped, scripted to only check that a file exists rather than that it is usable, or performed once at implementation and never repeated. ## Testing and verification discipline Verification is not a one-off activity. It is a recurring discipline that should be scheduled, resourced and documented in the same way as any other control. Step 1 Select a representative sample Include at least one critical system and one dataset from each backup medium in use. Step 2 Restore to an isolated environment Never restore directly into production for a test; use an isolated or sandboxed environment. Step 3 Verify integrity and completeness Check checksums or hashes where available, and confirm the restored data matches expectations. Step 4 Confirm operational recovery Where practical, bring the restored system into a working state and confirm it functions, not just that files exist. Step 5 Record and date the result Log what was tested, when, by whom, and the outcome, including any failures found and remediated. A minimum viable test restore cycle for the zero-errors requirement. ## How the rule maps to recognised guidance The 3-2-1-1-0 rule is not itself a formal published standard, but each of its elements is reflected in established guidance. [NIST SP 1800-11](https://www.nccoe.nist.gov/projects/data-integrity-recovering-ransomware-and-other-destructive-events) sets out practical patterns for maintaining and verifying recoverable data copies after a destructive event. The recovery function of the [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyfr/framework) expects organisations to test recovery plans and capability, not merely to hold copies of data. [NCSC UK's guidance on offline backups](https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world) and its [ransomware mitigation guidance](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks) both recommend an offline or logically separated copy and regular restore testing as core defensive measures, and [CISA's Ransomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) states the same expectation for US organisations, reinforcing that the additions to the classic 3-2-1 rule reflect converging guidance rather than a single vendor's marketing framework. ## How to evidence the rule to an auditor or insurer Cyber insurance renewal questionnaires and audit frameworks increasingly ask specific questions that a written backup policy alone does not answer. Evidence needs to be dated, specific and reproducible. Requirement Evidence to hold Common gap 3 copies Backup inventory listing each copy, its location and its storage system Copies counted that share the same underlying platform 2 media Architecture diagram naming each distinct storage technology in use Two products from one vendor treated as two media types 1 offsite Site and network documentation showing independent location and connectivity Offsite copy on the same corporate network as production 1 offline Connection logs showing scheduled online windows and their purpose No log exists because the copy was never truly offline 0 errors Dated test restore reports with outcome and remediation notes No test restore has ever been performed or documented What auditors and insurers typically expect to see against each part of the rule. The strongest evidence combines system generated logs, such as a tamper evident connection log for an offline copy, with human documented test restore reports. Insurers and auditors are increasingly asking for the connection log specifically, because a written policy stating that a copy is offline is not proof that it is. ## A practical compliance checklist - Confirm each of the three copies sits on genuinely independent underlying storage. - Confirm the two media types do not share a single management plane or vendor vulnerability. - Confirm the offsite copy has independent power, network and physical access controls. - Confirm the offline copy has no active network interface while disconnected, not merely a locked configuration. - Schedule and document test restores at a frequency aligned with your recovery time objective. - Keep dated evidence, including connection logs and restore reports, ready for audit or insurance renewal. ## Limits of the rule The rule is a resilience baseline, not a complete recovery strategy. It says nothing about recovery time objectives, the order in which systems should be restored, dependency mapping between applications, or the staffing and runbooks needed to execute a recovery under pressure. Organisations that satisfy every digit of 3-2-1-1-0 can still fail to recover quickly if they have not separately planned and rehearsed the operational sequence of a real incident. The rule also does not specify how quickly the offline copy can be brought back online, which is a legitimate design trade-off between security and recovery speed. An organisation should decide that trade-off deliberately, based on its recovery time objective, rather than let it be an accidental consequence of how the offline copy happens to be implemented. ## How Firevault applies these principles Firevault Offline Secure Storage® is designed specifically to satisfy the offline one in the 3-2-1-1-0 rule with a physical, Layer 1 disconnection rather than a logical or policy based one. The storage hardware has no network interface enabled while offline, so there is no IP address, no listening service and no credential path available to an attacker during that period. Connection windows are scheduled and identity verified through Firevault Control, an out-of-band management plane, and every connection and disconnection is recorded in a tamper evident log. That log, combined with a documented test restore process on the organisation's own backup platform, is the kind of paired evidence auditors and insurers are increasingly asking for against the offline and zero-errors requirements of the rule. Firevault does not replace the production or immutable cloud copies an organisation already relies on; it is designed to be the offline copy those approaches cannot themselves provide. Key takeaway ## The rule is a discipline, not a checkbox The 3-2-1-1-0 rule is easy to state and easy to claim compliance with while quietly failing on one of its five digits. The offline copy has to actually be offline, not merely locked. The zero has to come from a real, dated, evidenced test restore, not an assumption that backups which completed without an error message are therefore recoverable. Treated properly, the rule is a discipline of independent copies, independent media, independent locations, an independent network state, and independent proof, each one closing a failure mode the others do not. Questions ## Frequently Asked Questions Straight answers on how Offline Secure Storage® behaves in practice. ### What is the 3-2-1-1-0 backup rule? ### Where did the 3-2-1 backup rule come from? ### Why was one offline copy added to the rule? ### What does zero errors mean in 3-2-1-1-0? ### Does immutable cloud backup satisfy the offline requirement? ### How often should test restores be performed? ### How do the two different media in 3-2-1-1-0 help against ransomware? ### What counts as an offsite copy under the rule? ### How do you evidence the 3-2-1-1-0 rule to an auditor or insurer? ### What is the most common way the 3-2-1-1-0 rule fails in practice? ## Sources and further reading - [CISA and MS-ISAC, Ransomware Guide (StopRansomware.gov)](https://www.cisa.gov/stopransomware/ransomware-guide) Recommends maintaining offline, encrypted backups and regularly testing them, reflecting the offline and verification additions to the classic 3-2-1 rule. - [NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events](https://www.nccoe.nist.gov/projects/data-integrity-recovering-ransomware-and-other-destructive-events) Practice guide on maintaining recoverable, verified backup copies to recover data integrity after a destructive event. - [NIST Cybersecurity Framework 2.0, Recover function](https://www.nist.gov/cyfr/framework) Sets expectations for backup, restoration and verification as part of an organisation's recovery capability. - [NCSC UK, Offline backups in an online world](https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world) UK guidance explaining why an offline copy defeats a class of attacker that immutable-but-connected backup cannot. - [NCSC UK, Mitigating malware and ransomware attacks](https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks) Recommends keeping backups offline or in a separate network, and regularly testing that they can be restored. Related Firevault guides [Physical air gap storage for ransomware protection](/learn/physical-air-gap-ransomware-protection) [Air gap vs immutable backup](/learn/air-gap-vs-immutable-backup) [Hot storage vs cold storage](/learn/hot-vs-cold-storage) [What is Offline Secure Storage](/offline-secure-storage) About the author ![Mark Fermor](/assets/mark-fermor-aWtKNSv7.jpg) ### Mark Fermor [](https://www.linkedin.com/in/mfermor) Director & Co-Founder Co-founder of Firevault, focused on offline secure storage and protecting individuals and businesses from fraud, fines, loss and damage. Speaker, owner and advisor. Share this explainer Share [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule)[](https://twitter.com/intent/tweet?url=https%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule&text=The%203-2-1-1-0%20Backup%20Rule%20Explained%0A%0AThree%20copies%2C%20two%20media%2C%20one%20offsite%2C%20one%20offline%2C%20zero%20errors%20on%20recovery.%20This%20explainer%20traces%20the%20rule%20back%20to%20its%203-2-1%20origin%2C%20sets%20out%20what%20each%20added%20digit%20actually%20requires%2C%20and%20how%20to%20prove%20compliance%20rather%20than%20assume%20it.)[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule)[](mailto:?subject=The%203-2-1-1-0%20Backup%20Rule%20Explained&body=Three%20copies%2C%20two%20media%2C%20one%20offsite%2C%20one%20offline%2C%20zero%20errors%20on%20recovery.%20This%20explainer%20traces%20the%20rule%20back%20to%20its%203-2-1%20origin%2C%20sets%20out%20what%20each%20added%20digit%20actually%20requires%2C%20and%20how%20to%20prove%20compliance%20rather%20than%20assume%20it.%0A%0Ahttps%3A%2F%2Ffire-vault.com%2Flearn%2F3-2-1-1-0-backup-rule) The Firevault view**Offline Secure Storage® keeps a clean copy beyond the reach of an attacker.**[Why #OSS →](/why-oss) Control systems and access**Cut the physical paths attackers and third parties depend on.**[Explore Control →](/solutions/control) Get started**Get started, or talk to a member of the team.**[Get started →](/get-started)