3-2-1-1-0: the new backup baseline

The 3-2-1 backup rule has been the default backup guidance for about 20 years. 3 copies of your data, on 2 different media, with 1 copy offsite. It was sensible advice for an era when the primary threat to backups was a hardware failure, a flood or a fire.

Modern ransomware changed the threat model. Threat actors routinely encrypt or delete backup repositories before they trigger the production encryption, specifically because they know a victim with recoverable backups is a victim who will not pay. 3-2-1 does not address that. The updated rule, 3-2-1-1-0, does.

Here is what each digit requires in 2026, why it matters and where most mid-market firms actually fall short.

What 3-2-1-1-0 stands for

• 3 copies of your data
• 2 different media types
• 1 copy offsite
• 1 copy immutable or air-gapped
• 0 errors on the last restore test

The first three digits are the classic rule. The final two are the modern additions that address ransomware and operational-verification gaps.

3, three copies of your data

The production copy plus two backups. The intent is that the loss of any single copy does not destroy your recoverability.

Where firms fall short:

• A “backup” that is really a replica or a snapshot in the same storage system. Snapshots are useful for operational recovery but are not a second copy for disaster or ransomware purposes.
• A backup system that has been silently failing for weeks, so the production copy is the only copy, even though the dashboard says otherwise.

Confirming the count requires a documented inventory of what is being backed up and how many distinct copies exist. Most firms cannot produce that document on demand.

2, two different media types

Two different storage technologies, so a single failure mode cannot take out every copy. Historically this meant tape and disk. Today it usually means primary disk, secondary disk or object storage and then cloud.

Where firms fall short:

• Backing up to the same storage array the production system runs on. Fast to set up, offers zero protection against an array-level failure or a full-environment ransomware event.
• Using the same cloud provider for production and backup, in the same account, with no isolation between them. A compromised admin credential can delete both.

The principle is that the failure modes of the backup media are distinct from the failure modes of the production media. Diversity of failure mode matters more than the specific technology choice.

1, one copy offsite

Geographic separation from the primary copy. A fire or flood at the primary site cannot take out the backup.

Where firms fall short:

• The “offsite” copy is in the same office, in a desk drawer.
• The “cloud backup” is in the same metro region as the production environment, in the same availability zone, with no cross-region replication.

Offsite in 2026 usually means a different cloud region or a physically separate facility with documented geographic separation.

1, one copy immutable or air-gapped

The ransomware-era addition. One copy that cannot be modified or deleted by any credential an attacker might compromise during a typical intrusion.

Options in common use:

• Object-storage immutability. S3 Object Lock, Azure Blob immutable policies, equivalent on other providers. Once written, the object cannot be deleted or modified for the retention period, even by an account admin.
• Tape, stored offline. An older option that is coming back into fashion because it is the cleanest air gap available.
• Immutable appliance backup. Purpose-built backup appliances from vendors like Rubrik, Cohesity, Veeam (with hardened repository) or Wasabi that enforce immutability at the storage layer.

Where firms fall short:

• Calling a backup immutable because it is “in the cloud,” without verifying that immutability is actually enforced at the storage layer.
• Enforcing immutability only for a short retention window that a patient attacker could outwait.
• Keeping the immutability-enforcement credentials in the same password vault an attacker would compromise alongside the domain admin account.

Immutability is a storage-level guarantee, not a policy or a naming convention. If an admin account can delete or alter the copy, it is not immutable.

0, zero errors on the last restore test

The operational-verification addition. Backups that have never been restored are not backups. They are an optimistic assumption.

A real test has the following characteristics:

• A documented restore of a real dataset, not a dry run.
• A time measurement. How long did the restore actually take from request to usable state.
• A verification step. Did the restored data look correct, and was it usable by the application it came from.
• A frequency. At least quarterly for critical systems, at least annually for lower-tier systems.
• A written record with date, who performed it, what system, what result.

Where firms fall short:

• Treating a successful backup-job run as proof the backup works. The backup job finishing successfully and a restore actually succeeding are not the same thing.
• Running a restore test once, years ago, without any subsequent validation.
• Testing on a non-representative dataset that does not exercise the real recovery path.

A modern cyber insurance renewal usually asks explicitly for the date of the last successful full restore test. “Our backups run successfully every night” is not the answer the underwriter is looking for.

A practical self-assessment

A short version of the audit we walk mid-market firms through:

1. Can you name, in under 5 minutes, every system backed up, and produce a count of copies for each.
2. For each system, can you identify 2 distinct media types hosting the copies.
3. For each system, is at least one copy in a different geographic region.
4. For each critical system, is at least one copy immutable, with storage-layer immutability confirmed by the vendor documentation.
5. For each critical system, can you produce a dated restore-test record within the last 90 days.

A firm that answers yes to all 5 is in the top quartile for mid-market backup maturity. Most firms answer yes to 2 or 3 of the 5 and do not realize the gap until a ransomware event or a cyber insurance renewal exposes it.

What this looks like at Atticus Rowan

Our default cadence for managed clients includes monthly documented restore testing on a critical-systems subset, quarterly full-scope restore testing and an annual off-hours disaster-recovery rehearsal. Immutable cloud backup with documented immutability enforcement is a standard element of the managed engagement rather than an add-on.

The practical point is that 3-2-1-1-0 is not a technology sale. It is an operational discipline that sits alongside whatever backup vendor is in use. The tooling matters less than the configured retention, the tested restore and the evidence trail.

If your backup posture has not been reviewed against the 3-2-1-1-0 standard, or if your cyber insurance renewal is surfacing weak answers in the backup section of the application, schedule a discovery call. We can walk through the current posture and scope the specific lifts to bring it up to the modern baseline.