Why backup alone doesn't guarantee cloud recovery readiness

Backup maturity often falls short of recovery readiness

Enterprises sit at different points on the backup maturity curve. At the low end, backup is treated as a compliance checkbox. Data gets copied and the job is done. At the high end, backup is one component of a broader business continuity strategy that includes dependency mapping, automation and rehearsed failover exercises.

"Many organizations continue to struggle with the complexities of distributed architectures and modern application estates," said Gartner analyst Fintan Quinn. "In many cases, backup and recovery capabilities were treated as an afterthought."

Enterprise purchasing decisions have not kept pace with what recovery actually requires. Quinn said buyers often still focus on storage metrics and security features rather than recovery capabilities.

"There is still more interest in buzzwords such as immutability, air-gap, forensics and anomaly detection than there is in orchestration," he said.

That's a problem as more organizations try to consolidate fragmented backup environments. Quinn said the objective is typically a single pane of glass for visibility and control across on-premises and cloud platforms, with many users moving away from the native backup tools in data platforms toward third-party products to standardize governance and enforce consistent security policies.

Mature organizations go further. Quinn said they distinguish between data backup and full-service recoverability, a distinction that also applies to cyber recovery for complex data estates.

"The mature orgs have realized having just immutable backups is not enough," he said.

Backup success does not ensure service recovery

Even organizations that treat backup seriously run into a hard technical problem: Modern cloud services are not self-contained units of data. They rely on several layers of configuration, often externally owned or dynamically provisioned, that a standard backup does not capture. This is where recovery often stalls.

Forrester Research principal analyst Brent Ellis identified the root problem as a false equivalence. Many organizations still equate recovery with "data came back" instead of "the service is ready to run," he said.

"What's commonly missing from recovery plans is a clear map of service dependencies and the operational steps required to re-establish them in the right order," Ellis said.

Ellis cited the 2024 UniSuper incident as a case in point. UniSuper, an Australian superannuation fund, said an inadvertent misconfiguration during provisioning of private cloud services led to the deletion of its entire Google Cloud subscription.

"When their cloud account was deleted, they had backups of the data and VMs that were hosted in the cloud, but the relevant cloud tenant configuration was missing, and they had to recreate it," Ellis said. "This sort of incomplete context for recovery purposes plays out in different ways depending on how a workload is architected."

What shared responsibility covers -- and what it doesn't

The gap between restoring data and restoring a working service also raises a basic ownership question: Who is responsible for recovery if a cloud or SaaS platform fails? Shared responsibility is a common source of confusion here. Some enterprises think full backup and recovery is part of the provider's role, but provider obligations usually focus on availability and service resilience from their end.

For example, Microsoft and Salesforce both specify data protection is a shared responsibility. Microsoft says its disaster recovery copies on Microsoft 365 are not a substitute for backups, and it only maintains the current state of content. Salesforce says its backups are for infrastructure-level disaster recovery, and it cannot restore business-level data in other scenarios.

"Enterprises assume providers will restore a working service, but provider terms typically stop at platform availability, not full tenant recovery," Ellis said. "In SaaS especially, restore points are not full environments; they return data without reconstituting identity, integrations, workflows or configuration state."

Even organizations that accept their data protection responsibility face a structural barrier during prolonged SaaS outages.

"Because SaaS platforms are effectively black boxes with proprietary data models, customers can't simply switch to a competitor during a prolonged outage," Ellis said. "Moving requires decomposing data, re-mapping schemas, rebuilding integrations and retraining users. That mismatch between assumed recoverability and actual platform lock-in is why major SaaS incidents take far longer to recover from than enterprises expect."

How to evaluate backup tools beyond storage metrics

To evaluate cloud recovery readiness rather than storage alone, enterprises need to consider the capabilities that cover service dependencies, orchestration, configuration recovery and SLA scope.

Both Quinn and Ellis pointed to the same underlying problem: Buyers ask about data retrieval capabilities, not whether vendors can restore a service to working order.

Recovery is a purchasing issue as much as a technical one. Enterprises that evaluate only data protection features may end up rebuilding key parts of an affected service manually, while those that press vendors on orchestration, dependency recovery and testing are better positioned to understand what they are buying -- and to automate more of the recovery process.

"This is a capability area organizations should prioritize for cloud-native applications, particularly those mandated to have a rigorous, repeatable recovery testing capability," Quinn said.