Cloud Backups Aren't Backups Until You Test Them

The Comfort of Cloud Backups Is a Trap

I'll say it plainly: if you're using a cloud backup service and you've never done a full restore test, you don't have a backup—you have a hope. The convenience of cloud backups seduces us into thinking data is safe because it's synced to some distant server. But as NIST SP 800-209 points out, attackers don't just target primary data; they go after backups too, and can even poison future copies by interfering with the backup process. And CISA's guidance is blunt: maintain offline, encrypted backups and regularly test them. Yet most SMBs I talk to have never restored from their cloud backup. They don't know if their restore will work until the day it absolutely must. That's not a strategy; that's a gamble.

Why Cloud Backups Aren't Automatically Safe

Cloud backups are just another copy of your data, and they're subject to the same threats as any other copy—ransomware, insider threats, and even accidental deletion. The FBI's 2024 IC3 report notes ransomware complaints rose 9% from 2023, with 2,705 complaints and adjusted losses of over $12.4 million. And those numbers are artificially low, as the FBI itself cautions, because they don't include lost business, time, or third-party remediation costs. Ransomware has evolved to include storage components like NAS and backup appliances (NIST SP 800-209). So your cloud backup could be encrypted by ransomware if it's continuously connected and accessible.

That's why the 3-2-1 rule has evolved. CISA now promotes the 3-2-1-1-0 rule: three copies, on two different media, one off-site, one immutable or air-gapped, and zero unverified backups. An immutable copy is one that can't be altered or deleted after it's written (NIST SP 800-209 definition). Many cloud providers offer object lock or versioning to achieve immutability. But here's the catch: immutability doesn't help if you never test that you can actually restore from that immutable copy. A backup that's never restored is not a backup; it's just a theory.

And don't think snapshots are off the hook. NIST SP 800-209 defines a snapshot as a storage-efficient point-in-time copy, but it also warns that if the source data is unavailable, the snapshots are often useless. VMware's guidance is even more explicit: snapshots are not backups. They're change logs of the original disk. If the base disks are gone, snapshots alone can't restore a VM (Broadcom KB). So if your cloud backup is just a bunch of snapshots of your VMs, you might be in trouble.

Testing: The Missing Piece

So what does a real backup strategy look like? It includes testing, plain and simple. NIST SP 800-209 recommends testing backups at least monthly for critical data, and performing end-to-end test restores to a sandbox environment for applications with strict recovery speed requirements. That's not just a suggestion; it's a requirement for any serious data protection plan. CISA's ransomware response checklist also directs organizations to restore from offline, encrypted backups, ensuring you don't re-infect clean systems during recovery. But to do that, you need to know your backups work.

Let me give you a concrete scenario. Suppose your company has a database that must lose no more than five minutes of committed data (an RPO of five minutes) and be back online within one hour (an RTO of one hour). NIST SP 800-209 says point-in-time copies should be configured to meet the RPO—so if five minutes is the max, your snapshot interval should be five minutes or less. But even with that, if you've never tested a restore from those snapshots, you don't know if you can actually achieve that RTO. A test restore tells you how long it really takes, and whether the data is readable. It's the only way to verify your backup is worth the money you're spending on it.

Now, compare two common cloud backup approaches: continuous backup (like AWS Backup's continuous backups for S3, which allow point-in-time restore within the last 35 days) and periodic snapshots (which can be scheduled hourly, daily, weekly, etc., and retained for up to 99 years). Both have their place, but neither is a substitute for testing. Here's a comparison to help you think through it:

Whichever you choose, you must test. And don't forget the 0 in 3-2-1-1-0: zero unverified backups. That means every backup you have should be tested at some point. Not just a file-level restore, but a full system restore to a clean environment, to make sure everything works together.

What Testing Actually Looks Like

Testing doesn't have to be painful. Start with a single critical system. Restore it to a sandbox environment, ideally one that's isolated from your production network. Verify the data is intact and applications start. Time the entire process to see if it meets your RTO. Do this monthly for critical data, as NIST recommends. For less critical data, at least quarterly or annually. And keep a recovery catalog that records each copy and the results of anti-malware scans, as NIST SP 800-209 suggests. Periodically scan a subset of past copies with current anti-malware tools to catch poisoned backups.

One more thing: don't rely on high availability (HA) as a substitute for backup. NIST SP 800-34 explicitly states that HA systems cannot replace a solid backup strategy because a corruption can propagate through the HA system. So even if you have multi-site replication, you still need backups, and you still need to test them.

In the end, the cloud is just a location. The real backup is the one you can restore. So my recommendation is simple: schedule a full restore test today. It might take a few hours, but it's a lot cheaper than the alternative—losing your data and your business.

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 - https://www.ic3.gov/Media/PDF/AnnualReport/2024_IC3Report.pdf
• AWS Backup - https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html