The 3-2-1-1-0 rule turns a collection of backup jobs into a recoverable system: multiple independent copies, an off-site copy, an isolated or immutable copy and zero unaddressed errors after verification. The value lies in evidence, not in ticking five boxes.
Key point: a backup is not validated when the job ends. It is validated when the intended isolation is in place, the result has been checked and representative data can be restored within the required time.
What does the 3-2-1-1-0 backup rule mean?
The rule defines the number and characteristics of recovery copies. It is technology-neutral: its purpose is to prevent one failure, administrative mistake or compromised identity from affecting production and every backup at once.
| Number | Principle | Control question |
|---|---|---|
| 3 | Three instances of the data | Do production data and at least two genuine backup copies exist? |
| 2 | Two media or storage types | Could one common failure affect every copy? |
| 1 | One copy off site | Would a building incident remove every recovery option? |
| 1 | One offline, isolated or immutable copy | Can a compromised account still alter or delete it? |
| 0 | Zero errors after verification | Has the copy been checked and restored successfully? |
1. Keep three genuine instances of the data
The first instance is the production data. The other two must be independent backup copies. Version history on the same server is not enough: hardware failure, ransomware or an administrator error can reach the live data and its local history together.
Inventory critical file shares, virtual machines, databases, configurations, encryption keys and identity dependencies. For each dataset record the owner, change rate, recovery point objective and the business consequence of an unavailable restore.
2. Use two media or storage types
Diversity limits common-mode failures. A fast local copy may sit on dedicated storage while another is written to removable media. The objective is not technology for its own sake; it is to separate failure characteristics, administration and access paths.
- Separate storage locations and failure domains.
- Avoid using the same privileged accounts for every copy.
- Document the media, format, software and licence required to restore.
- Plan replacement for failed or end-of-life media and readers.
3. Maintain one off-site copy
An off-site copy protects against fire, flooding, theft and prolonged building outage. It may be held in another branch, a suitable safe or a controlled storage service. The process must specify who transports it, where it goes, when arrival is confirmed and how it can be retrieved during an incident.
Use stable media identifiers and record the backup date, location, operator, retention and latest verification. The register must locate the right copy quickly without exposing confidential data or credentials.
4. Maintain one offline, isolated or immutable copy
A copy is offline only when production can no longer reach it. Removable media must actually be ejected. A cartridge left in the reader or a repository permanently mounted with reusable credentials remains exposed to compromised accounts and destructive automation.
Logical isolation and immutability can also satisfy the objective when identities, management planes, networks, retention controls and deletion paths are genuinely separated. Test the complete attack path rather than relying on the Air Gap label.
Watch out: an off-site copy is not necessarily offline, and an offline copy is not necessarily off site. A resilient design satisfies both requirements.
5. Reach zero verified errors
Zero does not mean failures never occur. It means completed jobs have been reviewed, known errors have owners and representative restoration proves that the copy is usable. Verification must include the data, the tools, the people and the elapsed recovery time.
- Review job logs and alerts after every run.
- Check media health and readable capacity regularly.
- Restore a rotating sample of files every month.
- Run periodic application or system-level recovery tests.
- Compare measured recovery time and data age with RTO and RPO.
A practical small-business example
A small business may keep production on its server, a first recovery copy on dedicated local storage and a second copy on several RDX media in rotation. The daily medium is ejected after verification, one validated medium remains off site and another is ready for the next cycle.
Adapt the number of media and cadence to data volume, change rate and required recovery time. The guide Offline backup: organise media rotation in 5 steps explains the operating routine.
Monthly audit checklist
- Three identified instances of every critical dataset exist.
- The two media or systems do not share every failure and access risk.
- The off-site copy is at the expected controlled location.
- The isolated copy is no longer reachable from production.
- No job or verification error remains without an owner.
- A recent representative restore is documented.
- Available capacity still covers the intended retention window.
- Emergency credentials, readers and software remain available.
Start with the highest-impact data
Do not attempt to redesign everything at once. Select one critical service, implement all five requirements, restore it and document the gaps. Extend the method only after the first cycle works. Measured evidence will show where to change frequency, capacity, media count, isolation or off-site custody.
Assess your recoverability
Share your critical data, current copies and recovery targets to identify the most important gaps in your 3-2-1-1-0 design.
Share this guide

