Cloud backup and disaster recovery: a multi-cloud guide
A snapshot is not a backup. A backup is not a disaster recovery plan. Those two sentences are the whole reason this guide exists. Most “we have backups” statements fall apart under one question: when did you last restore one, and how long did it take? This is a practitioner’s walk-through of how to think about the problem before you pick a tool.
Backup vs disaster recovery: the distinction that matters
- Backup is a copy of data you can restore from. It answers “we lost this data, can we get it back?”
- Disaster recovery is the plan and capability to bring a whole environment back to a working state after a major failure. It answers “the region/datacentre/account is gone, how fast are we running again, and how much did we lose?”
Backup is one input to DR. You can have perfect backups and no disaster recovery, because restoring 40 TB across a rebuilt network with no runbook is a multi-day scramble, not a recovery. The rest of this guide is about building both deliberately.
The concepts that drive every decision
| Term | What it means | How it drives design |
|---|---|---|
| RTO (Recovery Time Objective) | How long you can be down before it hurts | Low RTO pushes you toward warm/hot standby, not cold restore |
| RPO (Recovery Point Objective) | How much data you can afford to lose (the gap since the last good copy) | Low RPO pushes you toward continuous replication, not nightly snapshots |
| 3-2-1 rule | 3 copies, on 2 media types, 1 off-site (ideally 1 immutable) | The baseline that survives a single-location or single-account failure |
| Immutability | Backups that cannot be altered or deleted for a set period (WORM) | The one control that actually defeats ransomware |
| Hot vs cold | Standby that is running (hot) vs spun up on demand (cold) | Hot = fast and expensive; cold = cheap and slow. Match to RTO |
Everything downstream (which service, how much replication, how much you spend) falls out of the RTO/RPO numbers in your SLA. Set those first. A workload that can tolerate a 24-hour RTO and a 24-hour RPO has a very different, much cheaper design than one that needs minutes.
The DR strategy spectrum
AWS’s four-tier model is the clearest way to think about the cost/speed trade-off, and it applies to every cloud:
- Backup and restore - cheapest, slowest. Restore from backups into a rebuilt environment. RTO hours to days. Fine for non-critical workloads.
- Pilot light - a minimal core (databases replicating, images ready) kept warm; scale up on disaster. RTO in tens of minutes.
- Warm standby - a scaled-down but running copy of the environment; scale it up on failover. RTO in minutes.
- Multi-site active/active - full capacity running in two or more locations. Near-zero RTO/RPO, highest cost.
Most organisations need different tiers for different workloads: active/active for the payment path, backup-and-restore for the internal wiki. Picking one tier for everything is how you either overspend or under-protect.
Not sure your RTO/RPO targets match your actual DR setup?
Book a free 30-min call
The native options, provider by provider
The principles are universal; the tooling differs. This is the landscape across the providers teams actually run.
| Provider | Backup | Disaster recovery |
|---|---|---|
| AWS | AWS Backup (central plans, Vault Lock immutability, cross-region/cross-account) | AWS Elastic Disaster Recovery (DRS) for server-level DR; Aurora Global Database, cross-region replication |
| Azure | Azure Backup (Recovery Services / Backup vaults, immutable vaults) | Azure Site Recovery (ASR) for VM replication and failover |
| GCP | Backup and DR Service, persistent disk snapshots | Regional/multi-regional resources, cross-region replication |
| OVHcloud | Veeam-based backup, snapshots, object storage | Multi-datacentre replication; often paired with Veeam or Zerto |
| DigitalOcean | Droplet backups, volume snapshots, Spaces | Snapshot-and-restore; DR usually built with third-party tooling |
| On-prem | Veeam, Commvault, Bacula; tape/disk | Replication to a second site or to a cloud as the DR target |
Two honest notes. The hyperscalers (AWS, Azure, GCP) have the deepest native backup/DR tooling; AWS Backup and Elastic Disaster Recovery, and Azure Backup with Site Recovery, are the most complete. OVH and DigitalOcean cover the basics natively (snapshots, backups, object storage) but DR beyond snapshot-and-restore is usually built with third-party tools such as Veeam or Zerto, or by using a hyperscaler as the recovery target. For the two biggest head to head, see our dedicated Azure Backup vs AWS Backup comparison.
Immutability and ransomware: the part not to skip
Ransomware changed the backup threat model. Attackers now target the backups first, because a victim with working backups does not pay. The defence is immutability: backups written once, unchangeable and undeletable for a defined period, ideally in an account or location the production credentials cannot reach.
- AWS: Vault Lock in compliance mode (not even root can delete until retention expires) plus cross-account backup.
- Azure: immutable vaults with soft delete on by default.
- On-prem/other: Veeam immutable repositories, object-lock on S3-compatible storage.
If you take one thing from this guide: an immutable, off-site, tested copy is the difference between a bad week and an existential event. Everything else is optimisation.
When DRaaS makes sense
Disaster recovery as a service (DRaaS) hands the replication, orchestration, and failover to a managed provider. It is the right call when:
- You lack the in-house team to build and (critically) test a DR setup.
- You need a defined RTO/RPO backed by someone else’s SLA.
- Your environment is on-prem or OVH/DigitalOcean and you want a hyperscaler as the recovery target without building it yourself.
It is not automatically cheaper than self-managed DR, and it adds a dependency. But for teams whose real risk is “we have a DR plan on paper that has never been exercised,” a managed service that runs regular failover tests is worth more than a cheaper setup nobody trusts.
A sane default approach
- Set RTO/RPO per workload class - not one number for everything.
- Apply 3-2-1 with one immutable, off-site copy - this is the floor, not the goal.
- Use native backup where your workloads live - AWS Backup, Azure Backup, GCP Backup and DR, cross-region and cross-account by default.
- Match the DR tier to the RTO - backup-and-restore for the long tail, warm standby or active/active for the critical path.
- Test the restore on a schedule - an untested backup is a hope, not a plan. Put failover drills in the calendar.
- Watch retention cost - lifecycle rules to tier and expire old recovery points; forgotten long-retention backups are the silent line item.
For how this fits the broader reliability picture, the Reliability pillar of a Well-Architected Review covers exactly these RTO/RPO and recovery-testing questions.
FAQ
What is the difference between backup and disaster recovery? Backup is a restorable copy of data. Disaster recovery is the plan and capability to bring a whole environment back after a major failure. Backup is one input to DR; having backups is not the same as being able to recover.
What are RTO and RPO? RTO (Recovery Time Objective) is how long you can be down. RPO (Recovery Point Objective) is how much data you can afford to lose. Both come from your SLA and drive the entire design.
What is the 3-2-1 backup rule? Three copies of your data, on two different media types, with one off-site. The modern addition is that one copy should be immutable, to survive ransomware.
Do I need DRaaS or can I build DR myself? Either can work. Build it yourself if you have the team to design and regularly test it. Use DRaaS when you want a provider’s SLA, lack the in-house capacity, or want a hyperscaler recovery target for on-prem/OVH/DigitalOcean workloads without building it.
How do I back up across multiple clouds? Run each cloud’s native backup where its workloads live, and standardise the policy (RTO/RPO, retention, immutability) across them, or use a third-party tool with cross-cloud support. Do not try to force one cloud’s backup service onto another cloud’s workloads.
Summary
- Backup, DR, and a tested recovery are three different things. Treating a backup as a DR plan is the most common and most expensive mistake.
- RTO and RPO drive everything. Set them per workload class, then match the DR tier (backup-and-restore through active/active) to each.
- Immutability is the ransomware defence, and testing is the proof. An immutable, off-site, regularly restored copy is the floor for every workload that matters.
If you want help designing backup and disaster recovery across AWS, Azure, GCP, or hybrid on-prem, explore our backup and disaster recovery services.
Designing backup and disaster recovery?
Book a free 30-minute call. We help teams set realistic RTO/RPO targets, design immutable multi-cloud backup, and run the failover tests that turn a DR document into a DR capability.
