Seven cloud disaster recovery myths, checked against public sources

Each myth below is paired with what a public source says. The sources are vendor pages, official cloud provider guidance and regulator or government publications, listed at the end.

Myth 1: "Our backups mean we can recover."

Backups bring back data. AWS's whitepaper on recovery options says that in a backup and restore strategy you must also redeploy the infrastructure, configuration and application code in the recovery region. Firefly's cloud disaster recovery page puts the same point as "Data Backup ≠ Service Continuity". A backup is necessary and not sufficient; see cloud backup vs infrastructure recovery.

Myth 2: "Everything is in Terraform, so we can rebuild."

Only what is in Terraform, and only as it was written. HCP Terraform can rebuild resources already in code; anything created by hand or by other tools is outside it. Drift detection in HCP Terraform runs through health assessments in the Standard and Premium editions only. Tools that generate code for unmanaged resources, such as Firefly, ControlMonkey and StackGuardian, exist because most estates are not fully codified. The lesson on infrastructure as code for recovery covers the gaps.

Myth 3: "A published RTO tells you how long our recovery will take."

A published RTO is a vendor claim about a vendor's conditions. Firefly states an RTO under one hour. Arpio publishes RPO targets, as low as 15 minutes in Standard, but no RTO. Commvault Cloud Rewind publishes neither on its product page. ControlMonkey's "85% faster recovery" is a customer figure, not an RTO. Your RTO depends on your application, your data volume and your team, and only a timed test on your own estate tells you what it is. See how to read a vendor's recovery claim.

Myth 4: "After ransomware we can restore in the same account."

If the attacker still holds credentials in that account, restoring into it can restore their access. Several vendors document a clean target for this reason: Firefly describes rebuilding into a clean, isolated region or account; Arpio states cross-account failover on AWS; Cohesity describes an isolated recovery environment in AWS and a clean room for investigation. CISA's #StopRansomware Guide recommends rebuilding systems by priority of critical services. The lesson on recovery targets sets out which target fits which incident.

Myth 5: "Immutable backups protect the whole environment."

Immutability protects the copies: they cannot be altered or deleted for a set period, including by administrators. Veeam, for example, describes always-immutable, encrypted, air-gapped backups for its cloud workloads. That protects the data layer. It does not recreate the network rules, IAM policies and DNS records the data needs, unless those are captured too.

Myth 6: "You cannot price cloud disaster recovery without a sales call."

Partly true. Arpio publishes the price of all three of its tiers, from $12k a year single-cloud, and Veeam publishes its SaaS rate of $42 per TB per month. Most other recovery capabilities in this ranking are Contact sales. Our briefing on budget scenarios shows what the published prices add up to.

Myth 7: "Regulators require a specific recovery tool."

They do not name products. DORA, applied since 17 January 2025, aims to let EU financial entities withstand, respond to and recover from ICT disruptions, and covers ICT risk management, resilience testing and ICT-related incidents among its areas. NIS2 requires covered entities to take appropriate cybersecurity risk-management measures and report significant incidents. What both create is a need to show that recovery works. Our briefing on DORA and NIS2 recoverability evidence lists what that evidence can look like.

What is the common thread?

Each myth treats one layer or one number as the whole answer. Recovery is a chain of layers (data, configuration, network, identity and DNS), and the weakest one sets the pace. The recovery scope matrix shows which layers each ranked vendor says it restores.