The 3-2-1 backup rule (three copies, two media types, one offsite) protects against the failures it was written for: a dead disk array, a corrupted volume, a flooded server room. It was never designed for an adversary who locates the backup catalog, deletes the repositories, and only then encrypts production. The extended 3-2-1-1-0 rule is meant to close that gap.
The extension adds one copy that is offline, air-gapped or immutable, and a requirement of zero errors after recovery verification. These force two questions the original rule never asked: can an attacker holding administrator credentials destroy every copy, and does anyone actually know the backups restore? This article explains each digit, how immutable object storage fits the extra copy, what "zero errors" means in practice, and closes with an illustrative layout and a checklist.
The 3-2-1-1-0 rule sets five minimum conditions for a backup strategy: three copies of the data, on two storage technologies, one copy offsite, one copy that is offline, air-gapped or immutable, and zero errors on verification. The first three digits are the classic rule; the last two were added as ransomware became the dominant recovery scenario.
The naive reading is that it simply means more copies. If every copy can be deleted with the same credentials, a fourth copy adds little. The extra "1" earns its place through independence from the control plane used everywhere else; the "0" replaces the assumption that backups work with evidence that they do.
Production plus at least two backups, so a single event such as a controller fault cannot destroy the data and its only backup together. Today this is usually a primary repository on premises for fast restores plus a second copy on another repository or an object store.
The backup copies should not share a failure mode: the same firmware bug, file system corruption or administrator account that can delete both. Historically that meant disk and tape; today it more often means a block or file repository plus an S3 object store.
Protection against fire, flood, power failure or regional outage, typically met by replication to a secondary data center or a copy job to a colocation facility or public cloud. Offsite does not mean protected from ransomware: a replica that inherits deletions from the source is still exposed.
This is the ransomware digit. It protects against an attacker who has compromised the backup server, hypervisor or domain and holds legitimate credentials. The copy must be one those credentials cannot modify or delete:
The failure here is silent: a job can report success while writing an image that cannot be mounted or a virtual machine that fails to boot. The requirement is that verification, not job status, reports zero errors.
| Digit | Threat addressed | Common implementations | Typical mistake |
|---|---|---|---|
| 3 copies | One failure destroying data and its only backup | Production plus primary repository plus secondary copy | Counting production array snapshots as a copy |
| 2 technologies | Shared failure mode across copies | Block or file repository plus S3 object store; disk plus tape | Two repositories on the same platform and admin account |
| 1 offsite | Site loss, regional outage | Secondary data center, colocation, cloud object store | Replication that faithfully propagates deletions |
| 1 offline / immutable | Attacker with backup or domain admin credentials | Ejected tape, isolated network target, S3 Object Lock compliance mode | Governance mode, or retention shorter than attacker dwell time |
| 0 errors | Silent corruption, unrestorable backups | Integrity scans, boot verification, scheduled test restores | Treating "job completed" as proof of recoverability |
Tape remains a legitimate offline copy, but it carries logistics many teams no longer staff for: library maintenance, media rotation, vault transport, and restores that wait on the right cartridge. An air gap avoids the media handling but still depends on scheduling discipline. Immutable object storage reaches the same outcome by making the copy logically undeletable for a defined period rather than physically separating it.
When the backup application writes an object with a retention period in compliance mode, the storage refuses any delete or overwrite until that period expires, regardless of who asks. A compromised backup server can still issue delete commands; it simply receives errors. Because retention is enforced at the storage layer, reconfiguring or uninstalling the backup application does not remove it.
Several design consequences follow. The account the backup application uses should hold only write permissions, so its compromise cannot alter bucket policies. Storage administration should use a separate identity with multi-factor authentication, held by different people than backup administration. Retention should exceed likely attacker dwell time, since an intruder present for weeks will simply wait out a short period. Major backup applications, including Veeam, Commvault, Rubrik, Cohesity and HYCU, write directly to object lock enabled buckets; in Veeam terms this is an immutable capacity tier of a scale-out backup repository or a direct object storage repository. Deployed at a second site, the same target also covers the second technology and the offsite copy.
A workable interpretation has three layers.
The backup application or storage system reads back stored data and compares it to checksums recorded at write time, catching bit rot and incomplete writes before a restore depends on them. Object stores generally do this continuously.
Most enterprise backup applications can mount a restore point in an isolated environment, boot it and run application-level checks on a schedule. A failure in that report means the backup is not counted as good, whatever the job status said.
Automated checks prove the data is readable; a test restore proves the people, procedures and infrastructure can bring a service back within the target time. It should be run from the immutable copy specifically, since a restore from the primary repository says nothing about the copy that will matter during an attack. Zero errors does not mean no problem is ever found; it means every problem found is fixed and the affected backups re-verified.
Suppose an organization runs roughly 400 virtual machines across two sites, holds about 150 TB of primary data, and targets restoring core services within 24 hours of a ransomware event. The figures are illustrative; the shape of the design is the point.
This gives three copies, two technologies, one offsite copy and one immutable copy. The "0" is met by weekly automated boot verification of the 40 most critical virtual machines, continuous integrity checking on both repositories, and a quarterly full restore of one business application from the Site B copy with the primary repository excluded. Two details are often missed: object storage administrative credentials sit with the infrastructure team rather than the backup team, and the 30-day retention reflects an incident plan that assumes an attacker may be present for several weeks before detection.
Scality ARTESCA is S3 object storage designed for backup, available as software or a hardware appliance, from tens of terabytes to petabytes. It supports S3 Object Lock, so restore points cannot be deleted or overwritten before their retention expires, which is what the rule's fourth digit requires.
ARTESCA is validated with major backup applications including Veeam, Commvault, Cohesity, Rubrik, HYCU, Veritas, Zerto, Acronis and IBM, so the immutable copy can be added as a repository within tooling a team already runs. Its security and cyber resilience features address the configuration details, such as separated administrative identities and multi-factor authentication, that decide whether immutability holds up in practice.
The practical takeaway: meet the immutable "1" by adding an object lock enabled repository to the backup application already in use, then prove the "0" by restoring from that repository on a schedule.