Backup and Recovery Architecture Guide: 3-2-1, 3-2-1-1-0, Immutability and Offline Copies

Share

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, 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, for the rule itself in depth.
• Air gap versus immutable backup, for the comparison in detail.
• Physical versus logical air gap, for what separation really means.
• Cyber insurance and 3-2-1-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® 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 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.

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.