Cloud Backup Isn't a Backup: Why Your Snapshot Won't Save You

Here's a number that should scare you: 48. That's how many hourly snapshots NIST SP 800-209 gives as an example of a tiered backup plan. Sounds generous, right? But here's the catch—snapshots are not backups. They're point-in-time copies that often use pointers, not full physical copies, and if the source data is unavailable, the snapshots will often not be usable either (NIST SP 800-209). In the cloud, where we're told to trust availability, we've seen too many teams treat snapshots as a get-out-of-jail-free card. They're not. This is the myth we need to bust.

What's the Difference Between a Snapshot and a Backup?

Let's get the terminology straight. A snapshot is a storage-efficient point-in-time copy that only stores changed blocks (Backup terminology). It's fast and cheap, which is why cloud providers love to sell them. But NIST SP 800-209 defines a backup as something that can be restored independently, and snapshots often fail that test. If your primary storage goes down, your snapshot may go down with it. A real backup, on the other hand, is a separate copy you can restore without depending on the original system. That's the whole point of the 3-2-1 rule: three copies, two different media, one off-site (CISA). Snapshots are great for quick rollbacks, but they're not a backup strategy.

Isn't Cloud Storage Automatically Off-Site and Safe?

Yes, cloud storage is off-site, but that doesn't mean it's safe. The 3-2-1 rule's off-site copy is about protecting against site-level disasters like fire or theft (Backup terminology). Cloud providers do replicate data across regions, but that's not the same as having a separate, independent backup. If you rely solely on cloud snapshots, you're still vulnerable to logical errors, ransomware that encrypts your snapshots, or even accidental deletion. NIST SP 800-209 warns that attackers target backups and may interfere with the backup process itself to poison future copies (NIST SP 800-209). So, your cloud copy is just another copy, not a backup, unless you've designed it to be immutable and separately restorable.

How Do RPO and RTO Affect My Cloud Backup Plan?

Let's talk about the two numbers that should drive every decision: RPO (Recovery Point Objective) and RTO (Recovery Time Objective). RPO is how much data you can afford to lose, measured in time; RTO is how fast you need to be back online (NIST). For critical systems, NIST assigns an RTO under 1 hour and an RPO under 5 minutes. That means you need backups that can restore data to within five minutes of the incident, and you need to be back up in under an hour. In the cloud, that might mean continuous data protection (CDP), where changed blocks are continually transmitted and journaled (NIST SP 800-209). But if your RPO is 24 hours, daily snapshots might be fine. The point is, your cloud backup frequency and type must match your RPO and RTO—not just what the cloud provider's default settings are.

Why Do I Need to Test My Cloud Backups?

Here's the uncomfortable truth: an untested backup is an assumption (NIST). CISA advises maintaining offline, encrypted backups and regularly testing them (CISA). But in the cloud, testing is often skipped because it's seen as a waste of time. That's a mistake. NIST SP 800-209 recommends testing backups at least monthly for critical data, and doing end-to-end test restores for applications with strict recovery requirements (NIST SP 800-209). Just last year, we saw a team that had been taking daily snapshots for months, only to discover they couldn't restore because the snapshots were corrupted. Testing would have caught that. It's not optional—it's the only way to know if your backup actually works.

What's the 3-2-1-1-0 Rule and Why Should I Care?

You've heard of the 3-2-1 rule, but there's a modernized version: 3-2-1-1-0. That's three copies, two different media, one off-site, one immutable or air-gapped, and zero unverified backups (CISA). The immutable copy is crucial in the cloud. Immutability means data can't be altered or deleted after it's written (NIST SP 800-209). This protects against ransomware that might try to encrypt your backups or a malicious insider. Cloud providers offer object lock features, but you have to enable them. And the 'zero unverified' part ties back to testing—every backup should be verified, not just assumed to be good.

How Should I Choose Between File Backups, Image Backups, and Snapshots?

Let's compare the options in a table:

NIST SP 800-209 distinguishes file backups (logical structures like files) from image backups (entire LUNs). In the cloud, you might use file backups for critical configuration files and image backups for entire EC2 instances. But remember, snapshots are not backups—they're a convenience. Use them for quick recovery, but always pair them with a true backup that's independent and tested.

So, What's the Single Most Important Thing to Remember?

Cloud backup is not automatic. Just because your data is in the cloud doesn't mean it's backed up. You need to design a plan that meets your RPO and RTO, use immutable copies to protect against ransomware, and test your backups monthly. The most important thing to remember: a backup you haven't tested is not a backup—it's just data sitting somewhere. So, go test your cloud backup today.

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
• NIST Glossary - https://csrc.nist.gov/glossary