Cloud Backup Isn't Just a Copy: A Field Guide to the 3-2-1-1-0 Rule

Imagine you're the IT manager at a mid-sized marketing agency. One Tuesday morning, you get an alert: your cloud storage bucket—the one holding years of client campaign assets—has been encrypted. The ransomware note demands payment in Bitcoin. You check the backup dashboard and realize your last verified restore test was six months ago, and the backups you have are stored in the same cloud account as the primary data. You're not alone. The FBI's 2024 Internet Crime Report notes ransomware complaints rose 9% from 2023, and the real losses are likely far higher because they don't include lost business, time, or wages (FBI IC3 2024 Internet Crime Report). This is the nightmare that cloud backup is meant to prevent, but only if it's done right.

I've spent years in the trenches of data protection, and I've seen too many organizations treat cloud backup as a simple "copy to S3 and forget it." That's a recipe for disaster. The modern threat landscape demands a more rigorous approach. The good news is that the principles and technologies exist to make your cloud data genuinely resilient. Here's my field report on how to actually do it.

The 3-2-1-1-0 Rule: Your Cloud Backup Foundation

You've probably heard of the classic 3-2-1 rule: three copies of your data, on two different storage media, with one copy off-site (CISA data backup guidance). But in the cloud era, that's not enough. CISA now advocates for the 3-2-1-1-0 rule, which adds one immutable or air-gapped copy and zero unverified backups (CISA data backup guidance). This isn't just academic. NIST SP 800-209 defines immutability as the ability to lock data after creation, preventing alteration or deletion (NIST SP 800-209). That's your defense against ransomware that tries to encrypt or delete your backups.

In our scenario, the marketing agency's primary data lives in an AWS S3 bucket. The first step is to enable S3 Versioning, which AWS requires before you can back up the bucket (AWS S3 backup User Guide). Versioning gives you a history of objects, but it's not a backup—it's a feature. You need a separate, immutable copy. That's where AWS Backup comes in. AWS Backup can create continuous backups for point-in-time restore within the last 35 days, or periodic snapshots that can be retained for up to 99 years (AWS Backup S3 backups Developer Guide). For the immutable copy, store it in a separate AWS account or use S3 Object Lock, which enforces a write-once-read-many (WORM) model. The key is that this copy is isolated and cannot be modified or deleted by an attacker who compromises your primary account.

Know Your RPO and RTO: Numbers That Save Your Bacon

Before you configure any backup, you need to define your recovery objectives. Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time—how far back you can restore. Recovery Time Objective (RTO) is how fast you must be back online (NIST contingency planning). For mission-critical systems, NIST suggests an RTO under 1 hour and an RPO under 5 minutes (NIST contingency planning). In our agency scenario, the client campaign data might be Tier 1, requiring a 5-minute RPO. That means you need continuous backup or very frequent snapshots. AWS Backup's continuous backups for S3 allow restore to any point in time within the last 35 days, which can meet a 5-minute RPO (AWS Backup S3 backups Developer Guide).

But here's a critical nuance: NIST SP 800-209 warns that snapshots, if used as backups, must be configured to meet the RPO. If you need 5-minute granularity, your snapshot interval must be 5 minutes or less (NIST SP 800-209). Also, remember that snapshots are often storage-efficient point-in-time copies that store only changed blocks, but they are not standalone backups—they depend on the source data. If the source volume is lost, snapshots may be useless (NIST SP 800-209). That's why you need a real backup, not just snapshots.

Immutability and Air Gaps: Your Ransomware Shield

Ransomware attackers don't just target primary data; they go after backups too. NIST SP 800-209 identifies compromising backups as a key risk, noting attackers may interfere with the backup process to gradually poison future copies (NIST SP 800-209). That's why immutability is non-negotiable. In cloud, you can achieve an air gap by using a separate AWS account for backups, with strict IAM policies that prevent deletion. Or you can use tape. The LTO Program touts LTO tape as an inherent air gap solution, since tape cartridges are offline and not susceptible to online attacks (LTO Program). LTO-9 cartridges offer up to 45 TB compressed capacity and support WORM functionality (LTO Program). That's a solid off-site, immutable copy.

In our scenario, the agency should implement a hybrid approach: AWS Backup for fast, granular recovery, but also a periodic tape export or a copy to a separate cloud provider for true air-gapped resilience. The FBI's 2024 report lists Akira, LockBit, and RansomHub among the top variants (FBI IC3 2024 Internet Crime Report), and these groups are known to infect backup systems. Don't give them that chance.

Testing and Continuous Improvement: Because Hope Is Not a Strategy

The '0' in 3-2-1-1-0 means zero unverified backups. An untested backup is just an assumption. NIST recommends testing backups at least monthly for critical data, and performing end-to-end test restores to a sandbox environment (NIST SP 800-209). In our scenario, the agency should schedule a monthly automated restore test of a representative sample of objects, and a quarterly full restore to a separate test bucket. Also, keep a recovery catalog that records each copy and scan results to identify poisoned backups (NIST SP 800-209).

One more thing: high availability is not backup. NIST SP 800-34 warns that HA systems with 99.999% uptime can't replace backups because data corruption can propagate through replication (NIST SP 800-34). So don't rely on multi-region replication alone. You need point-in-time copies.

Quick tip: When configuring AWS Backup for S3, set a lifecycle expiration rule for versioning-enabled buckets. Without it, storage costs can skyrocket as AWS Backup retains all versions (AWS S3 backup User Guide).

The single most important thing to remember: cloud backup is not a feature you switch on; it's a discipline you practice. Define your RPO/RTO, enforce the 3-2-1-1-0 rule with immutable copies, and test relentlessly. Your future self—and your clients—will thank you.

Sources

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