Cloud Backup: Why 3-2-1 Fails Without an Air Gap

I still see smart people treating the 3-2-1 backup rule as the finish line. Three copies, two media, one off-site. That was a breakthrough when Peter Krogh came up with it. But these days, ransomware gangs don't just encrypt your servers—they hunt your backups first. And 3-2-1 alone? That's a liability.

Here's the contrarian bit: if your off-site copy is a cloud bucket that your production credentials can delete, you don't have a backup. You have a hostage. The modern rule is 3-2-1-1-0: add one immutable or air-gapped copy, and zero unverified backups. That extra “1” and “0” are the whole ballgame.

What question are we actually answering?

We're not surveying the entire cloud backup market. The narrow question is: when does a cloud backup actually count as a backup, and when is it just a replica that will die with your primary? That's the decision we make every time we design a recovery strategy. Get it wrong and you're writing ransom checks or explaining to the board why the “backup” was encrypted along with everything else.

Let's define terms. A backup is a copy of data that can be restored independently of the source. A replica depends on the source's availability and integrity. The cloud blurs this line because cloud storage is just someone else's computer—and that computer is often reachable with the same credentials that run your workloads. NIST SP 800-209 defines immutability as the ability to lock data after creation, preventing alteration or deletion. That's the property that turns a cloud copy into a real backup. Without it, you have a replica.

Why the cloud makes 3-2-1 harder, not easier

Off-site used to mean tapes in a vault or a colo across the country. Now it often means an S3 bucket or a managed backup service. The convenience is real, but so is the attack surface. NIST SP 800-209 identifies compromising backups as a key risk, noting attackers target backups and copies just as much as primary data—and may interfere with the backup process to gradually poison future copies. Ransomware has evolved to include storage components like NAS and backup appliances. If your cloud backup is reachable from a compromised workstation, it's not a backup.

We've seen this movie. The FBI's 2024 IC3 report describes ransomware as the most pervasive threat to critical infrastructure, with complaints rising 9 percent from 2023. IC3 received 2,705 ransomware complaints in 2024, with adjusted losses of $12,473,156. Those loss figures are artificially low because they exclude lost business, time, wages, and remediation, and many victims never report. The real cost is downtime. That's where RTO comes in.

The numbers that drive architecture: RPO and RTO

Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time. Recovery Time Objective (RTO) is the maximum acceptable downtime before systems must be restored. These aren't vague goals; they dictate your backup frequency and method. Mission-critical systems often get an RTO under 1 hour and an RPO under 5 minutes. Less critical systems can tolerate longer. NIST SP 800-209 advises that if a business standard requires no more than five minutes of committed data lost, your snapshot interval must be five minutes or less. That's a concrete engineering constraint.

Here's where cloud shines: continuous backup. NIST SP 800-209 describes continuous data protection (CDP) as a form of backup where changed blocks are continually transmitted and journaled, supporting fine-grained recovery and improved RPO. AWS Backup for S3 offers continuous backups that allow restore to any point in time within the last 35 days, while periodic snapshot backups can be retained for up to 99 years and scheduled at frequencies like 1 hour, 12 hours, 1 day, 1 week, or 1 month. That's a powerful toolkit—but only if you configure it to meet your RPO.

We use a simple example to make this real. Say you run a SaaS app with a 5-minute RPO and a 2-hour RTO. You enable AWS Backup continuous backups on your S3 buckets. The first backup is full; subsequent backups are incremental at the object level. For buckets with more than 300 million objects, the initial backup can run at up to 17,000 objects per second; smaller buckets back up at closer to 1,000 objects per second. That initial full backup could take days. If your RTO is 2 hours, you can't wait for a full re-upload during a disaster. You need the continuous journal to restore point-in-time, not the periodic snapshots.

Immutability and air gaps: the only real ransomware defense

This is where the 3-2-1-1-0 rule earns its keep. The extra “1” is an immutable or air-gapped copy. Immutability can be logical (object lock, WORM) or physical (tape offline). LTO tape provides an inherent air gap solution, giving organizations greater confidence they can recover data after an attack; disk storage, while faster to recover, is not offline and not completely secured from ransomware.

We're not saying everyone needs tape. But everyone needs at least one copy that cannot be deleted or altered by a compromised credential. In AWS, that means S3 Versioning plus AWS Backup vault lock, or a separate account with restricted permissions. AWS states that S3 Versioning must be activated before AWS Backup can back it up, and recommends a lifecycle expiration rule for versioning-enabled buckets to control cost, because AWS Backup retains all versions. That lifecycle rule is a double-edged sword: set it too aggressively and you lose versions; set it too loosely and you pay for storage you don't need.

For databases, the same logic applies. Amazon RDS automated backups create a storage volume snapshot of the entire DB instance; the first snapshot is full, subsequent snapshots are incremental. These are stored in S3. But RDS snapshots are not immutable by default. You need to copy them to a vault with lock, or use a separate account. Otherwise, an attacker with the right IAM permissions can delete them.

Snapshots are not backups. We repeat that because it's the most common mistake. NIST SP 800-209 defines a snapshot as a storage-efficient point-in-time copy that stores only changed data, and notes that if the source data is unavailable, snapshots often aren't usable either. Broadcom/VMware states plainly that VMware snapshots are not backups: a snapshot file is only a change log of the original virtual disk, and if the base disks are deleted, the snapshot files alone are not sufficient to restore a VM. A maximum of 32 snapshots is supported in a chain, but Broadcom/VMware recommends only 2 to 3 for performance, and advises not to retain a single snapshot for more than 72 hours because the file grows and can fill storage. Yet we still see teams treating a week-old snapshot as their disaster recovery plan.

Testing: the “0” in 3-2-1-1-0

The “0” stands for zero unverified backups. An untested backup is an assumption. NIST SP 800-209 recommends testing backups at least monthly for critical data, and performing end-to-end test restores to a sandbox for applications with strict restoration speed requirements. CISA advises maintaining offline, encrypted backups and regularly testing them. The ransomware response checklist says to restore from offline, encrypted backups based on prioritization of critical services, taking care not to re-infect clean systems.

We've seen teams pass a “backup test” that only checks whether the backup job completed. That's not a test. A test is restoring a database to a point in time, booting an application, and validating data integrity. NIST SP 800-53 control CP-9(1) requires testing backup information at an organization-defined frequency to verify media reliability and information integrity. We recommend quarterly full restores for Tier 1 systems, monthly for Tier 2. That's not overkill; it's the only way to know your RTO is real.

Keep a recovery catalog. NIST SP 800-209 advises recording each copy and the results of anti-malware scans, and periodically scanning past copies with current anti-malware tools to identify poisoned copies. If you don't know which backup is clean, you don't have a recovery plan.

What about high availability? It's not a substitute. NIST SP 800-34 states that HA systems cannot replace a solid backup strategy because data corruption can propagate through an HA system, making recovery impossible without a backup separate from the system itself. We've watched synchronous replication faithfully copy a ransomware encryption event to the standby site. That's not protection; it's fast propagation.

What I'd actually do

If you're running cloud workloads today, here's the concrete plan we'd implement:

• Classify data into tiers. Tier 1 gets RPO under 5 minutes, RTO under 1 hour. Tier 2 gets RPO under 1 hour, RTO under 4 hours. Tier 3 gets daily backups, RTO under 24 hours. Document this and map every data store to a tier.
• Enable continuous backup where RPO demands it. For S3, use AWS Backup continuous backups (35-day point-in-time restore) plus periodic snapshots for long-term retention. For RDS, enable automated backups with a retention period that meets your RPO, and copy snapshots to a locked vault.
• Add an immutable copy. Use S3 Object Lock in compliance mode or AWS Backup Vault Lock. For on-prem, keep at least one LTO tape offline. The LTO Program notes that LTO-9 offers up to 45 TB compressed capacity and hardware-based encryption, and the roadmap targets 1.44 PB per tape by LTO-14. Tape is not dead; it's the air gap.
• Test quarterly. Restore a Tier 1 database to a sandbox, boot the app, and run integrity checks. Document the actual RTO you achieved. If it's over target, fix it before an incident.
• Protect encryption keys separately. NIST SP 800-209 requires that if encrypted data is backed up, the keys be protected for a similar duration, and data and keys not be kept together. Use a separate key management account with strict access controls.

Cloud backup is not a product you buy; it's a property you engineer. The 3-2-1 rule got us started, but 3-2-1-1-0 is the minimum for surviving ransomware. The extra immutable copy and the discipline of testing are what separate a real recovery from a hopeful one. We'd rather spend the budget on a locked vault and quarterly restore drills than on a ransom negotiation.

Sources

• CISA (data backup guidance) - https://www.cisa.gov/stopransomware
• NIST SP 800-209 (Storage Infrastructure Security) - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
• NIST SP 800-34 Rev. 1 (Contingency Planning Guide) - https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
• AWS Backup (S3 backups Developer Guide) - https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html
• LTO Program (NewsBytes September 2022) - https://www.lto.org/newsbytes-september-2022/
• FBI IC3 2024 Internet Crime Report - https://www.ic3.gov/Media/PDF/AnnualReport/2024_IC3Report.pdf