--- title: "Backup and Recovery Architecture Guide: 3-2-1,… | Firevault" description: "The consolidated technical guide to backup and recovery architecture: what 3-2-1 and 3-2-1-1-0 mean, how immutability actually works, where offline copies…" 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/guides/backup-and-recovery-architecture-guide#webpage", "url": "https://fire-vault.com/learn/guides/backup-and-recovery-architecture-guide", "name": "Backup and Recovery Architecture Guide: 3-2-1,…", "description": "The consolidated technical guide to backup and recovery architecture: what 3-2-1 and 3-2-1-1-0 mean, how immutability actually works, where offline copies…", "isPartOf": { "@id": "https://fire-vault.com/#website" }, "about": { "@id": "https://fire-vault.com/#organization" }, "primaryImageOfPage": { "@type": "ImageObject", "url": "https://zomvctmqpgirvjnvawlz.supabase.co/storage/v1/object/public/article-images/guides/backup-and-recovery-architecture-guide.jpg" }, "inLanguage": "en-GB", "breadcrumb": { "@id": "https://fire-vault.com/learn/guides/backup-and-recovery-architecture-guide#breadcrumb" } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "@id": "https://fire-vault.com/learn/guides/backup-and-recovery-architecture-guide#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://fire-vault.com" }, { "@type": "ListItem", "position": 2, "name": "Learn", "item": "https://fire-vault.com/learn" }, { "@type": "ListItem", "position": 3, "name": "Guides", "item": "https://fire-vault.com/learn/knowledge?filter=guides" }, { "@type": "ListItem", "position": 4, "name": "Backup and Recovery Architecture Guide: 3-2-1, 3-2-1-1-0, Immutability and Offline Copies", "item": "https://fire-vault.com/learn/guides/backup-and-recovery-architecture-guide" } ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "Backup and Recovery Architecture Guide: 3-2-1, 3-2-1-1-0, Immutability and Offline Copies", "description": "The consolidated technical guide to backup and recovery architecture: what 3-2-1 and 3-2-1-1-0 mean, how immutability actually works, where offline copies differ, and how to design and test a recovery path.", "url": "https://fire-vault.com/learn/guides/backup-and-recovery-architecture-guide", "image": "https://zomvctmqpgirvjnvawlz.supabase.co/storage/v1/object/public/article-images/guides/backup-and-recovery-architecture-guide.jpg", "author": { "@type": "Person", "name": "Mark Fermor", "worksFor": { "@id": "https://fire-vault.com/#organization" }, "url": "https://fire-vault.com/why-oss/about" }, "publisher": { "@id": "https://fire-vault.com/#organization" }, "datePublished": "2026-08-28T07:23:16.054012+00:00", "dateModified": "2026-08-28T10:12:43.171224+00:00", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://fire-vault.com/learn/guides/backup-and-recovery-architecture-guide" }, "inLanguage": "en-GB", "articleSection": "Technical Guides", "wordCount": 1137, "isAccessibleForFree": true, "copyrightHolder": { "@id": "https://fire-vault.com/#organization" }, "copyrightYear": 2026 } ] --- Recent Breaches Breaches [2026 PowerSchool 62.4M records ](https://www.bleepingcomputer.com)[2026 DISA Global Solutions 3.3M records ](https://techcrunch.com)[2026 Globe Life 850K records ](https://www.securityweek.com)[2026 Lidl GB Customer contact data ](https://www.theguardian.com/business/2026/jun/11/lidl-gb-third-party-data-breach)[2026 Asahi Group Production systems disrupted ](https://www.reuters.com/technology/cybersecurity/asahi-says-cyberattack-disrupted-operations-japan-2025-09-29/)[2026 Kido International 8K records ](https://www.bbc.co.uk/news/articles/c623d7v0e5xo)[2026 Collins Aerospace (RTX) Check-in and boarding disruptio... ](https://www.bbc.co.uk/news/articles/c789e7l1z7po)[2026 Jaguar Land Rover Production and IT systems disru... ](https://www.bbc.co.uk/news/articles/cx2gx8p3rzeo)[2026 Peter Green Chilled Order and logistics data ](https://www.bbc.co.uk/news/articles/c0k7yy8n3g5o)[2026 Adidas UK Customer contact details ](https://www.bbc.co.uk/news/articles/c78jkev1el2o)[2026 PowerSchool 62.4M records ](https://www.bleepingcomputer.com)[2026 DISA Global Solutions 3.3M records ](https://techcrunch.com)[2026 Globe Life 850K records ](https://www.securityweek.com)[2026 Lidl GB Customer contact data ](https://www.theguardian.com/business/2026/jun/11/lidl-gb-third-party-data-breach)[2026 Asahi Group Production systems disrupted ](https://www.reuters.com/technology/cybersecurity/asahi-says-cyberattack-disrupted-operations-japan-2025-09-29/)[2026 Kido International 8K records ](https://www.bbc.co.uk/news/articles/c623d7v0e5xo)[2026 Collins Aerospace (RTX) Check-in and boarding disruptio... ](https://www.bbc.co.uk/news/articles/c789e7l1z7po)[2026 Jaguar Land Rover Production and IT systems disru... ](https://www.bbc.co.uk/news/articles/cx2gx8p3rzeo)[2026 Peter Green Chilled Order and logistics data ](https://www.bbc.co.uk/news/articles/c0k7yy8n3g5o)[2026 Adidas UK Customer contact details ](https://www.bbc.co.uk/news/articles/c78jkev1el2o) [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) Overview The rules, stated preciselyWhat "one copy immutable or offl…"Zero errors" is a verification …Designing the recovery pathWhere the architecture usually f…Related detail in this clusterWhere physical controls contributeFrequently asked questionsMore [Guides](/learn/knowledge?filter=guides)/ Technical Guides Technical Guides · 28 August 2026 # Backup and Recovery Architecture Guide: 3-2-1, 3-2-1-1-0, Immutability and Offline Copies The consolidated technical guide to backup and recovery architecture: what 3-2-1 and 3-2-1-1-0 mean, how immutability actually works, where offline copies differ, and how to design and test a recovery path. ![Mark Fermor](/assets/mark-fermor-aWtKNSv7.jpg) Mark Fermor Director & Co-Founder, Firevault 6 min read Share [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffire-vault.com%2Flearn%2Fguides%2Fbackup-and-recovery-architecture-guide)[](https://twitter.com/intent/tweet?url=https%3A%2F%2Ffire-vault.com%2Flearn%2Fguides%2Fbackup-and-recovery-architecture-guide&text=Backup%20and%20Recovery%20Architecture%20Guide%3A%203-2-1%2C%203-2-1-1-0%2C%20Immutability%20and%20Offline%20Copies%0A%0AThe%20consolidated%20technical%20guide%20to%20backup%20and%20recovery%20architecture%3A%20what%203-2-1%20and%203-2-1-1-0%20mean%2C%20how%20immutability%20actually%20works%2C%20where%20offline%20copies%20differ%2C%20and%20how%20to%20design%20and%20test%20a%20recovery%20path.)[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ffire-vault.com%2Flearn%2Fguides%2Fbackup-and-recovery-architecture-guide)[](mailto:?subject=Backup%20and%20Recovery%20Architecture%20Guide%3A%203-2-1%2C%203-2-1-1-0%2C%20Immutability%20and%20Offline%20Copies&body=The%20consolidated%20technical%20guide%20to%20backup%20and%20recovery%20architecture%3A%20what%203-2-1%20and%203-2-1-1-0%20mean%2C%20how%20immutability%20actually%20works%2C%20where%20offline%20copies%20differ%2C%20and%20how%20to%20design%20and%20test%20a%20recovery%20path.%0A%0Ahttps%3A%2F%2Ffire-vault.com%2Flearn%2Fguides%2Fbackup-and-recovery-architecture-guide) ![Backup and Recovery Architecture Guide: 3-2-1, 3-2-1-1-0, Immutability and Offline Copies](https://zomvctmqpgirvjnvawlz.supabase.co/storage/v1/object/public/article-images/guides/backup-and-recovery-architecture-guide.jpg) Technical Guides Why it matters ## What this means for organisations holding critical data The consolidated technical guide to backup and recovery architecture: what 3-2-1 and 3-2-1-1-0 mean, how immutability actually works, where offline copies differ, and how to design and test a recovery path. **On this page**[The rules, stated precisely](#section-0)[What "one copy immutable or offl…](#section-1)["Zero errors" is a verification …](#section-2)[Designing the recovery path](#section-3)[Where the architecture usually f…](#section-4)[Related detail in this cluster](#section-5)[Where physical controls contribute](#section-6)[Frequently asked questions](#section-7) On this page 1. [The rules, stated precisely](#section-0) 2. [What "one copy immutable or offline" actually distinguishes](#section-1) 3. ["Zero errors" is a verification requirement, not a slogan](#section-2) 4. [Designing the recovery path](#section-3) 5. [Where the architecture usually fails](#section-4) 6. [Related detail in this cluster](#section-5) 7. [Where physical controls contribute](#section-6) 8. [Frequently asked questions](#section-7) **Written by Mark Fermor.** This is the umbrella technical guide for backup and recovery architecture. It explains the rules people quote, what they mean in engineering terms, and how to design a recovery path that survives an attacker with valid administrative credentials. ## The rules, stated precisely **3-2-1** means three copies of data, on two different media types, with one copy off site. It originated as protection against hardware failure, site loss and [human error](/threats/human-error), and it remains sound for those threats. **3-2-1-1-0** extends it for the ransomware era: three copies, two media, one off site, one copy that is immutable or offline, and zero errors on verification. The final two digits carry most of the modern value, and are the two most often unevidenced. Neither rule is a standard. No regulator mandates them and no certificate exists. They are useful shorthand for a design conversation, and increasingly they appear on cyber insurance proposal forms, which is why precision about the fourth and fifth elements matters commercially as well as technically. ## What "one copy immutable or offline" actually distinguishes These are not synonyms, and treating them as interchangeable is the most consequential error in this area. - **Immutable** means the copy cannot be modified or deleted for a defined retention period, enforced by software or firmware. Object lock in compliance mode, hardened repositories with a separate authorisation domain, and write-once media all qualify to varying degrees. Immutability is enforced by a system that is itself reachable, administered and licensed. Its strength is exactly the strength of the separation between the retention authority and production administration. - **Logically air gapped** means the copy is separated by credentials, network policy or account boundary while remaining reachable in principle. This is meaningfully better than a domain-joined backup server, and it still shares a control plane with something an attacker can reach. - **Physically disconnected** means there is no electrical or network path to the copy at the moment of an attack. No credential, however privileged, and no software defect in the retention mechanism can reach it while it is disconnected. The practical test to apply to any claim is a single question: which identity, system or vendor could shorten the retention, disable the lock, or delete the copy, and does an attacker who owns production administration also own that? If the answer is yes, the copy is a convenience copy, not a recovery guarantee. ## "Zero errors" is a verification requirement, not a slogan Backup success is not recovery capability. Verification must establish that the data is readable, that it is internally consistent, that the application can start from it, and that it is free of the malware or corruption that prompted the recovery. Modern intrusions frequently dwell for weeks, so restoring the most recent copy can restore the intrusion. A defensible verification regime includes automated integrity checking, periodic application-level recovery testing rather than file-level spot checks, retention long enough to reach behind a realistic dwell time, and a record of results with timings. ## Designing the recovery path Backups are inputs. The recovery path is the system. Design it explicitly, and document what it depends on. 1. **Set recovery objectives per service,** not per estate. Recovery time objective, recovery point objective, and the minimum viable service you would run in the interim. 2. **Enumerate recovery dependencies.** Identity, DNS, certificates and keys, licence servers, hypervisor management, network configuration, the backup catalogue itself, and the documentation describing the procedure. Each one that lives only inside the affected estate is a single point of failure in the recovery. 3. **Reduce shared failure domains.** Ask whether the recovery copy shares an administrative domain, an authentication provider, a hypervisor, a storage platform or a network path with the environment it exists to restore. 4. **Plan for order and bandwidth.** Restoring twenty terabytes over a link sized for incremental change is a schedule problem that no amount of immutability solves. 5. **Include the human path.** Who authorises recovery, how they are contacted if email and telephony are unavailable, and where the runbook exists in a readable form. 6. **Rehearse under realistic constraints.** A restore performed with full production tooling available is not a test of a ransomware scenario. ## Where the architecture usually fails - The backup infrastructure is joined to the same directory as production, so one privileged compromise reaches both. - Immutability is enabled in governance mode rather than compliance mode, which permits privileged deletion. - Retention is shorter than attacker dwell time, so every surviving copy contains the intrusion. - The recovery documentation and credential material live on the systems being recovered. - Recovery has been tested per file or per virtual machine, never as a service, and never against the stated recovery time objective. - Off site means a second data centre reachable from the first over a flat management network. ## Related detail in this cluster - [The 3-2-1-1-0 backup rule explained](/learn/3-2-1-1-0-backup-rule), for the rule itself in depth. - [Air gap versus immutable backup](/learn/air-gap-vs-immutable-backup), for the comparison in detail. - [Physical versus logical air gap](/learn/physical-vs-logical-air-gap), for what separation really means. - [Cyber insurance and 3-2-1-1-0](/compliance/cyber-insurance-3-2-1-0), for how underwriters read these controls. ## Where physical controls contribute Everything above is achievable with mainstream backup engineering, and most organisations should improve their retention, separation and testing before considering anything else. The residual problem is narrow and specific: for the small set of assets whose loss would end the recovery, a software-enforced protection and the asset it protects can share a fate if the enforcing system is itself compromised. Firevault's **[Offline Secure Storage](/offline-secure-storage)®** addresses that residue by holding selected recovery, configuration and evidential material on dedicated storage that is physically disconnected when it is not being accessed, with identity-[controlled access](/news/controlled-access-buyers-guide-offline-secure-storage) and a record of each interaction. **Control by Firevault** is a suite of nine purpose-built tools and techniques that give physical control over the paths into and across an estate, applied through Blueprints that treat a specific risk, which is relevant where the path to a recovery set does not need to exist continuously. This complements operational backup and recovery rather than replacing it. The question it answers is whether the copy you would need most should share a reachable failure domain with the environment it may one day be required to restore. ## Frequently asked questions ### Is 3-2-1-1-0 a standard? No. It is industry shorthand, though it is increasingly referenced in insurance and procurement questionnaires. ### Is immutable the same as air gapped? No. Immutability is enforced by a reachable system for a retention period. A physically disconnected copy has no path to it at all while disconnected. ### How long should retention be? Long enough to reach behind realistic attacker dwell time, which for many intrusions means months rather than weeks, and long enough to satisfy your regulatory retention duties. ### How often should recovery be tested? At service level, on a defined cycle, and after material change to the estate or the recovery tooling. Record timings against your recovery time objective. 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. 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) How Firevault would handle this ## A recovery copy an attacker cannot reach Offline Secure Storage® keeps a clean copy of your data on hardware that is physically disconnected, so backup and recovery do not depend on systems an intruder can touch. [Get started](/get-started)[Talk to the team](/demo) **Hardware**Your copy sits on dedicated encrypted hardware **Disconnect**Offline by default, connected only when you say so **Recovery**A known-clean copy to rebuild from, on your timetable **Location**Held in a secure Firevault Bunker ## Continue learning - [ ### Operating Without Systems: Incident Response When every connected system is encrypted or compromised, how does your team actually operate? This guide covers the practical reality of incident response when your tools, communications, and documentation are all unavailable. Read guide ](/learn/guides/operating-without-systems) - [ ### Cost of Paying Ransoms: Why Payers Still Lose Paying a ransom does not end a ransomware incident. It begins a longer, more expensive, and more damaging process that organisations without recovery independence are forced into. Understanding the true cost changes the calculation entirely. Read guide ](/learn/guides/cost-of-paying-ransoms) - [ ### Credential Governance: Managing Your Keys Every system, every backup, every recovery procedure depends on credentials. When those credentials are compromised or inaccessible, technical capability becomes irrelevant. Credential governance through OSS ensures the keys to your kingdom survive any incident. Read guide ](/learn/guides/credential-governance) - [ ### Recovery Independence: No Compromise The single greatest weakness in most disaster recovery strategies is circular dependency: the plan to recover from a system compromise is stored on systems that can themselves be compromised. Recovery independence eliminates this fatal flaw. Read guide ](/learn/guides/recovery-independence) Related Reading ## You may also find these useful [ ![Airport WiFi sign-ups turn into a national data problem as 8.7 million customer records are accessed](https://zomvctmqpgirvjnvawlz.supabase.co/storage/v1/object/public/article-images/manchester-airports-group-data-breach-2026.jpg) Insight ### Airport WiFi sign-ups turn into a national data problem as 8.7 million customer records are accessed Manchester Airports Group has confirmed that criminal hackers accessed the data of about 8.7 million customers across Manchester, East Midlands and London Stansted. Most of it came from free terminal WiFi sign-ups and from car parking, lounge and fast-track bookings. 27 Aug 2026 5 min ](/news/manchester-airports-group-data-breach-87-million-customers-2026)[ ![Premier League moves the goalposts as cyber rulebook introduces 22 security control areas](https://zomvctmqpgirvjnvawlz.supabase.co/storage/v1/object/public/article-images/premier-league-cyber-rulebook-2026.jpg) Regulation ### Premier League moves the goalposts as cyber rulebook introduces 22 security control areas Rule J.9 and Appendix 11 put cyber security into the Premier League rulebook, with phased deadlines, annual evidence and 22 control areas spanning club, stadium and supplier operations. 27 Aug 2026 14 min ](/news/premier-league-cyber-rulebook-appendix-11-2026)[ ![T-Mobile pulled the plug on Salt Typhoon. It took a car journey to get there.](https://zomvctmqpgirvjnvawlz.supabase.co/storage/v1/object/public/article-images/tmobile-power-pull-salt-typhoon-2026.jpg) Insight ### T-Mobile pulled the plug on Salt Typhoon. It took a car journey to get there. T-Mobile's security chief ended months of failed software remediation by driving to the data centre, clearing ID, finding the cabinet and physically pulling the power supply from the compromised hardware. Disconnection was the right control. Firevault Control is designed to take the same action in under six milliseconds. 27 Aug 2026 7 min ](/news/tmobile-severs-network-cable-salt-typhoon-hackers-2026) ![Mark Fermor](/assets/mark-fermor-aWtKNSv7.jpg) ![David Bailey](/assets/david-bailey-Dgqj8eaE.jpg) ![Kenny Phipps](/assets/kenny-phipps-CVyooRsR.jpg) Online Now Concierge ## Put this guide into practice Ready to apply what you have learned? Explore how Firevault delivers the offline protection covered in this guide. Takes about 2 minutes. No account needed. Find Out Free 2 mins No sign-up