The rule at a glance
The 3-2-1 backup rule reduces dependency on any single system or location. Its weakness is that it does not require any copy to resist deletion or modification — and an attacker who compromises the backup administrator account can delete backup jobs, reduce retention, erase cloud repositories and disable recovery accounts just as easily as a legitimate operator can.
The 3-2-1-1-0 model strengthens the traditional strategy by adding two requirements: one protected copy and zero unverified recovery errors. The complete model is:
The UK National Cyber Security Centre says cloud and on-premises backups are not ransomware resistant by default. Its principles call for protection from destructive actions, continued customer access, recovery from older versions, robust key management and alerts for significant or privileged changes.
Why the extra one and the zero matter
Multiple copies help with hardware failure and accidental deletion. They do two different jobs:
Veeam describes the 3-2-1-1-0 model as an extension of the classic rule, adding one immutable or air-gapped copy and zero recovery errors. The term is an industry backup framework rather than a universal regulatory standard.
Offline, air-gapped and immutable are not identical
These terms are often grouped together, but they describe different controls.
Offline backup
An offline backup is physically or logically disconnected when it is not being used — an ejected LTO tape, an unplugged USB disk, or a repository powered down between controlled backup windows. Malware cannot directly access media that is not connected. The trade-offs are manual handling, slower recovery, and the risk that rotation is skipped.
Air-gapped backup
An air gap creates isolation between the protected backup and the production environment. A physical air gap uses disconnected media or networks. A logical air gap may use separate credentials, separate identity systems, restricted network routes, delayed synchronization or a service that blocks direct destructive commands. A logical air gap is only as strong as its configuration — a repository described as air-gapped may still be exposed if the same administrator account controls both production and backup.
Immutable backup
An immutable backup cannot be overwritten or deleted during a defined retention period. Amazon S3 Object Lock, for example, uses a write-once, read-many model and can prevent protected object versions from being deleted or overwritten during retention. Object Lock requires S3 Versioning and applies protection to individual object versions. Immutability lets the backup remain online and available for recovery while protected from normal deletion — but incorrect retention configuration, excessive storage consumption, or an account that can bypass governance controls all remain risks. Immutability protects a recovery point from change; it does not prove the recovery point is clean or usable.
Which protected copy should you choose?
Use offline tape when
Use immutable object storage when
Use a hardened repository when
Use rotated removable disks when
Rotated disks can satisfy the protected-copy requirement, but only when the process is followed consistently.
Reference architectures
A practical Proxmox architecture
Current Proxmox Backup Server documentation recommends recurring verification jobs and reverifying all backups at least monthly, because previously valid data can degrade over time. Verification should be followed by periodic VM and application recovery tests — checksum verification alone cannot confirm that an operating system boots or that an application functions correctly.
A practical homelab architecture
Critical recovery information should also be protected: encryption keys, password manager recovery details, network and hypervisor configuration, DNS records, application secrets and backup software configuration.
A practical small business architecture
The recovery plan should assume that normal company systems may be unavailable — do not store the only copy of recovery instructions inside the environment those instructions are meant to recover.
How to implement the extra one
Select the critical recovery points
Not every backup requires identical protection. Start with systems whose loss would stop operations or cause permanent data loss: identity services, virtualization management, databases, customer records, financial systems, source code, configuration repositories, encryption keys, file servers, backup catalogs.
Choose the protection mechanism
Choose offline, air-gapped or immutable storage based on recovery speed, data volume, change rate, retention period, available bandwidth, operational skill, compliance requirements, budget, physical security and restore location.
Separate administrative control
The account that manages production should not automatically be able to destroy every backup. Use separate backup administrator accounts, multifactor authentication, restricted deletion privileges, separate cloud accounts or subscriptions, protected emergency credentials, and alerts for destructive operations.
The NCSC recommends controls that stop compromised customer accounts from deleting backup data, and separate mechanisms for exceptional destructive requests.
Set a realistic retention period
Immutability requires advance planning. A period that's too short may expire before an attack is detected; too long creates unnecessary storage cost and prevents legitimate deletion. Consider how long compromise may remain undetected, legal retention requirements, available capacity, and daily/monthly change rate.
Protect keys and recovery credentials
Encrypted backups can become unrecoverable when their keys are lost. Keep protected copies of encryption keys, recovery passwords, cloud account recovery codes, hardware security keys, backup configuration and required licence information — stored separately from the production environment.
Monitor protected storage
Protection should generate evidence. Monitor failed backup and verification jobs, retention policy changes, unusual deletion attempts, unexpected growth, repository capacity, disabled alerts, new privileged accounts and synchronization delays. A silent backup system is difficult to trust.
Achieving the zero
The final zero requires several levels of testing, from monitoring to a full disaster recovery exercise.
CISA recommends maintaining offline encrypted backups and regularly testing their availability and integrity in a disaster recovery scenario, because ransomware frequently attempts to delete or encrypt accessible backups.
Suggested verification schedule
Critical systems may require more frequent testing.
Common 3-2-1-1-0 mistakes
Cloud storage does not become immutable simply because it is offsite. Retention controls must be enabled, enforced and tested.
One compromised account should not control production, local backups, cloud storage and retention policies.
Snapshots may be deleted with the production system unless they are replicated to an independent protected destination.
A removable disk permanently attached to the backup server is online storage. Disconnect it after backup and verification completes.
Locked data cannot be pruned before retention expires. Estimate storage growth before enabling long retention periods.
Checksum verification can prove stored blocks haven't changed. It cannot prove a database is consistent or a recovered service will start.
An intact encrypted repository is useless when the decryption key cannot be found during recovery.
A recent backup may contain corrupted, encrypted or already-compromised data. Test recovery from different points in the retention window.
The plan may become inaccessible during the incident. Keep a protected offline copy with required contacts, credentials and recovery steps.
3-2-1-1-0 assessment checklist
0 / 18A low score does not necessarily mean you need a new backup product — it usually means the current systems need stronger separation, retention, monitoring or testing.
Frequently asked questions
It is an extension of the traditional 3-2-1 backup strategy. It recommends three copies of data, two storage systems or media, one offsite copy, one offline, air-gapped or immutable copy, and zero unverified recovery errors.
The modern 3-2-1-1-0 terminology is associated particularly with Veeam, which describes it as an extension of the classic 3-2-1 backup rule. The underlying practices of offline backups, protected retention and recovery testing are also supported by government cybersecurity guidance.
No. An offsite backup may still be online, mutable and controlled by the same compromised credentials. The protected copy should resist deletion or modification.
Not always. Immutable online storage offers fast access and protected retention. Offline media provides stronger physical separation. Important environments may use both.
Yes, when the tape is ejected, securely stored and not accessible through the production environment. Tape handling, encryption and restore testing still matter.
It can when the provider and backup application support enforced object retention or equivalent immutability. Versioning alone is not the same as immutable retention.
It means backup and recovery errors are detected, investigated and resolved. It also means important backups are verified through real restoration, not only job completion reports.
Monitor every backup run, verify repository integrity regularly and perform periodic file, system and application restores. The exact frequency should follow the importance and recovery objectives of the workload.
Yes. A second machine, encrypted cloud copy, rotated offline disk and scheduled restore test can provide a practical implementation without enterprise software.
It cannot prevent an attack. It improves the chance of retaining a usable recovery path after production systems or ordinary online backups have been compromised.
Build for recovery, not backup completion
The strongest part of the 3-2-1-1-0 rule is the final zero. The protected copy keeps an attacker from easily destroying every recovery point. Verification shows that the protected copy contains something you can actually use.
A backup dashboard full of successful jobs can create false confidence. Recovery confidence comes from independent copies, restricted destructive access, protected credentials and repeated restoration. Start by protecting one critical workload — create an independent local backup, move another copy offsite, protect one recovery point from deletion, and complete a real restore. Then repeat the process for the next system.