Sign In Sign Up
Cloud Backup

Cloud Backup: Why I Stopped Trusting the 3-2-1 Rule (and You Should Too)

The old 3-2-1 backup rule isn't enough anymore. Ransomware evolved. Here's how to build a cloud backup strategy that actually survives an attack—without the hype.

By The DR Desk September 07, 2026 2 views Calculating...

Tuesday, 8:47 AM. That's when the first ticket came in. "I can't open any files—they all have a weird extension." Then the phone started ringing. By 9:15, we had a full-blown ransomware incident on our hands. Every file server, every workstation, even the backup NAS we kept in the server room—all encrypted. The attackers wanted 40 bitcoin. We didn't have that. And when I checked our cloud backup, I felt sick: the sync client had been replicating encrypted files for hours, overwriting the good versions. Our "backup" was useless.

I'm not making this up. The FBI's IC3 report for 2024 shows ransomware complaints jumped 9% from 2023, with over 2,700 complaints and adjusted losses of $12.4 million—but they admit that's just the tip of the iceberg. The real cost, when you add downtime and lost business, is often ten times higher. (Check the FBI IC3 2024 Internet Crime Report if you don't believe me.)

So, let's talk about cloud backup. Not the "should I use it" question—that's settled. The real question is: Is your cloud backup actually ransomware-proof? Most people assume it is. But the cloud isn't a magic shield. In fact, attackers know exactly where you keep your backups, and they go after them first. NIST SP 800-209 says so explicitly: ransomware has evolved to target backup storage, including NAS devices and cloud snapshots. So, what does a resilient setup look like? It's not the old 3-2-1 rule. It's the 3-2-1-1-0 rule—but with a few twists you won't find in the glossy brochures.

Why the 3-2-1 Rule Let Me Down

The classic rule says: keep three copies of your data, on two different media, with one off-site. Sounds solid, right? But here's the flaw: if your "off-site" copy is synced in real-time to your network, it's just another attack surface. Ransomware doesn't care if your backup is in the cloud—if it can find your credentials, it can delete or encrypt that copy too. And thanks to always-on sync, the malware often corrupts your cloud backup before you even notice something's wrong.

I once saw a company lose 30 TB of data because their cloud backup was a simple mirror. They had no versioning, no immutability. The ransomware encrypted the files on the server, and the sync client dutifully uploaded the encrypted versions, overwriting the good ones. Their "backup" was a perfect copy of the disaster. That's when I realized: high availability is not a backup. If your primary and backup share the same credentials or the same sync mechanism, you're fooling yourself.

The 3-2-1-1-0 Rule—What It Actually Means

So, what's the fix? CISA and NIST now recommend a beefed-up rule: 3 copies, 2 different media, 1 off-site, 1 immutable or air-gapped, and 0 unverified backups. Let's break that down without the jargon.

First, you need three copies: the original, a local backup (like a NAS), and a cloud backup. The two different media bit is easy in the cloud age: local disk and object storage. The off-site copy is your cloud backup. But the crucial part is the second '1'—an immutable copy. That means a copy that even you can't delete or alter for a set period. Think of it as a digital safe that only opens after the timer runs out.

How do you get immutability in the cloud? Most providers offer something like AWS S3 Object Lock, which enforces a write-once-read-many (WORM) state. Once you lock an object, not even the root user can delete it until the retention period expires. But here's the catch: you have to enable versioning first, and you need to set a lifecycle policy to avoid runaway costs. AWS explicitly warns that without a lifecycle rule, your storage bill can balloon because every version is kept forever. (See AWS S3 backup User Guide.)

But immutability isn't enough if your credentials are in the same place as the rest of your network. If an attacker compromises your Active Directory, and your backup admin account is in that same AD, they can log into your cloud console and delete everything—even the immutable copies, if they can change the retention settings. The fix? Use a separate AWS account for backups, with a separate IAM role that requires multi-factor authentication. Store those credentials in a physical safe or a password manager that's not connected to your main network. NIST SP 800-53 CP-9(3) mandates that backup information be stored in a separate facility or fire-rated container. In the cloud, that "separate facility" is a different account with strict access controls.

The Hardest Part: Testing Restores (and Actually Doing It)

Here's a confession: for years, I never tested a restore. I set up backups, checked that the logs said "success," and moved on. Then I read a NIST SP 800-209 recommendation that said to test backups monthly for critical data, and to do an end-to-end restore in a sandbox environment for applications with strict RTO requirements. So, I tried it. And it took three weeks to restore 10 TB from our cloud provider. Our RTO was 24 hours. We were dead in the water.

That's the "0" in 3-2-1-1-0: zero unverified backups. If you haven't tested your restore process, you don't have a backup—you have a hope. And it's not just about speed. You also need to verify the integrity of your backups. Some ransomware variants lie dormant for weeks, waiting until your backups are also infected before striking. So, you need to scan your backups for malware, not just assume they're clean. NIST SP 800-209 suggests keeping a recovery catalog that records each copy and the results of anti-malware scans, and periodically scanning past copies with current tools.

Here's a specific tip I picked up: when you test a restore, don't just restore files to a folder. Restore an entire server into a sandbox, boot it up, and run your applications. That's the only way to know if your backups are actually usable. It's a pain, but it's cheaper than paying a ransom or explaining to your board why you lost everything.

Choosing a Provider: What to Look For (and What to Avoid)

So, how do you pick a cloud backup provider that supports this? First, look for immutability features—object lock or WORM storage. AWS Backup, for example, lets you create backup vaults that are immutable by default, with retention periods from 1 day to 99 years. That's great for long-term retention, but you also need to know your RTO. Ask the provider: "If I need to restore 10 TB, how long will it take?" If they can't give you a straight answer, run away.

Second, think about cost. Cloud backup isn't free, and if you're not careful, you'll be paying for storage you don't need. Set up lifecycle policies to tier your backups: keep daily backups for 30 days, weekly for 6 months, monthly for 7 years. That's a reasonable approach, and NIST SP 800-209 recommends specifying tiering, frequency, and number of copies for each tier.

Third, consider the restore process. Can you do a granular restore (like one file), or do you have to restore the whole bucket? For databases, you might need point-in-time recovery. AWS RDS, for instance, automatically backs up your DB instance and retains them for a configurable period, with the first snapshot being full and subsequent ones incremental. That's fine, but you need to know your RPO. If you can't afford to lose more than five minutes of data, your snapshot interval should be five minutes or less. Don't assume that a daily backup is enough.

Finally, think about the "air gap." In the cloud, a true air gap is impossible—your data is always connected to the internet. But you can simulate it by storing your immutable backups in a separate account that has no network path from production. Some providers offer "cold storage" tiers like S3 Glacier, which have retrieval times of minutes to hours. That's not a true air gap, but it's better than nothing. The LTO Program (tape) is the only real air gap, but let's be honest—tape is slow and clunky. For most organizations, a cloud-based immutable copy in a separate account is sufficient, as long as you've locked it down properly.

A Quick Word on Security Hygiene

Before I wrap up, here's a simple but critical tip: enable multi-factor authentication on your backup account, and use a separate email address for that account—one that you don't use for anything else. Also, regularly review who has access to your backup vault. The principle of least privilege applies to backups too. I can't tell you how many times I've seen companies with a backup admin account that has full access to everything, shared among five people. That's a disaster waiting to happen.

And one more thing: don't forget to document your backup and recovery procedures. If you get hit with ransomware, you'll be in a panic. You need a clear, step-by-step runbook that tells you exactly what to do, including who to call and how to access your immutable backups. Trust me, you don't want to be figuring that out at 2 AM.

So, Is Cloud Backup Your Ransomware Insurance?

Only if you do it right. That means implementing the 3-2-1-1-0 rule, but with the caveats I've mentioned: separate accounts, strict access controls, and regular testing. It's not glamorous, and it takes effort, but the alternative—paying a ransom or going out of business—is far worse. The FBI's IC3 report shows that ransomware is not going away; it's evolving. So, take the time to set up your cloud backup correctly. Your future self will thank you.

Sources

Share this article:

Tags:

#3-2-1-1-0 rule #ransomware protection #immutable backups

Comments (0)

No comments yet. Be the first to comment!

Related Articles