Cloud Backup Isn't Offsite Until You Test It: A 5-Step Walkthrough

Who This Is For

You've got a NAS or a server and you think you're safe because you pay for cloud backup. Here's the uncomfortable number: if your business or compliance standard demands no more than five minutes of data loss, your snapshot interval must be five minutes or less (NIST SP 800-209). Most cloud backup defaults are hourly or daily. That's a five-minute RPO you're not meeting. This walkthrough is for you if you're the one who'll be explaining to the boss why last night's backup didn't restore.

Step 1: Define Your RPO and RTO Before You Touch Settings

Recovery Point Objective (RPO) is the maximum data loss you can stomach; Recovery Time Objective (RTO) is how long you can be down (NIST). For mission-critical systems, NIST suggests an RTO under 1 hour and an RPO under 5 minutes. That's a high bar. Most home labs and small businesses can't hit that with cloud alone. So be honest: if you can lose 4 hours of work, set snapshots to 4 hours. But here's the catch—your RTO must be shorter than your Maximum Tolerable Downtime (MTD) (NIST SP 800-34). If you can't survive more than 12 hours down, and your cloud provider takes 24 hours to restore a full server, you've failed before you've begun.

Step 2: Don't Mistake Snapshots for Backups

Cloud providers love selling snapshots. They're storage-efficient and fast, but NIST SP 800-209 is blunt: if the source data is unavailable, the snapshots will often not be usable either. That's because snapshots live on the same infrastructure. A ransomware attack that hits your primary storage can poison your snapshots too. The fact base is clear: attackers target backups specifically, and they may interfere with the backup process to gradually poison future copies (NIST SP 800-209). So you need a real backup, not just a snapshot. That means a separate copy in a different location, ideally immutable or air-gapped—the 3-2-1-1-0 rule from CISA adds that one immutable copy and zero unverified backups.

Step 3: Set Cloud Backup Tiers Like a Pro

You don't back up everything the same way. NIST SP 800-209 advises organizing your data protection plan by tier, with specific frequency and copy counts per tier. For example, you might keep 48 hourly snapshots for Tier 1 data and 30 daily backups for Tier 2. That's from the fact base. So sit down and categorize: Tier 1 is your customer database, financials, maybe your active projects. Tier 2 is your archive and old files. Your cloud backup software should let you set different schedules per folder or VM. If it doesn't, you're using the wrong tool. And note: the same level of protection you use on primary storage—encryption, access controls—must carry over to your cloud backup (NIST SP 800-209). Don't assume your provider encrypts everything; check.

Step 4: Test Your Restore—Monthly, Not Annually

Here's where most people fall off. You've set up cloud backup, you see 'Last backup: success' and you breathe easy. But NIST SP 800-209 recommends testing backups at least monthly for critical data, and doing an end-to-end test restore to a sandbox environment if you have strict RTO requirements. That's not a suggestion; it's a requirement for anyone who actually cares about recovery. Untested backups are assumptions. So pick a Saturday, restore a single file from last week. Then restore a full VM to a separate sandbox. Time it. If your RTO is 4 hours and the restore takes 6, you've got a problem. Also, keep a recovery catalog that records each copy and the results of anti-malware scans—and scan past copies periodically with current tools to catch poisoned backups (NIST SP 800-209).

Step 5: What Can Go Wrong (and How to Avoid It)

Here's the nightmare scenario: a ransomware attack hits, you log into your cloud console, and your backups are gone. Why? Because the attacker had your cloud credentials and deleted them. NIST SP 800-209 warns that attackers target backups and may interfere with the backup process. The fix is immutable backups—storage that can't be altered or deleted, even by an admin. The 3-2-1-1-0 rule from CISA explicitly calls for at least one immutable or air-gapped copy. So turn on object lock or versioning in your cloud provider, and make sure your backup software supports it. Also, follow CISA's ransomware response checklist: if you're hit, take a snapshot of volumes for forensic review, but don't restore from a snapshot that might be compromised—restore from offline, encrypted backups. And if you have to recover, prioritise critical services and be careful not to re-infect clean systems (CISA).

Sources

• CISA (data backup guidance) - https://www.cisa.gov/stopransomware
• CISA ransomware response checklist - https://www.cisa.gov/stopransomware/ive-been-hit-ransomware
• 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