Topic starter
09/07/2026 3:24 pm
TL;DR: Multi-cloud backup often protects data service by service, but recovery still fails when teams must restore synchronised applications across clouds, accounts, and admin domains, according to Commvault. The real control gap is not storage durability but orchestration, dependency mapping, and governed automation across the full recovery path.
Editorial analysis by NHI Mgmt Group, based on content published by Commvault: “Multi-Cloud Recovery That Actually Works”.
Key questions
Q: What breaks when multi-cloud backup is treated as the same thing as recovery?
A: Service-level backup protects data, but recovery fails when teams cannot restore the full application state in the right sequence across clouds, accounts, and identities.
Q: Why do cross-cloud dependencies make recovery slower in practice?
A: Cross-cloud recovery slows down because each cloud, account, and admin domain can impose a different recovery point, approval path, or restore sequence.
Q: What are the signs that application recovery is not actually ready?
A: The clearest signs are siloed backup ownership, different teams controlling related services, and no tested sequence for restoring the application as a whole.
Practitioner guidance
- Map application recovery dependencies Identify which services, data stores, secrets, and control-plane dependencies must come back together for each critical application to function.
- Test cross-cloud restore sequences Run recovery tests that span clouds, accounts, and regions so sequencing failures appear before a real incident does.
- Govern recovery automation identities Review the permissions granted to backup jobs, orchestration agents, and recovery scripts so they can do only the tasks required.
Bottom line: Multi-cloud backup can give a false sense of resilience when application dependencies span multiple clouds and admin domains.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 3:43 pm
Application-level resilience is now a governance problem, not a storage problem. Multi-cloud environments expose a basic control mismatch: backup is usually organised by service, while recovery must happen at the application layer. That gap is amplified by separate clouds, separate admin domains, and separate ownership models. Practitioner conclusion: resilience programmes need application dependency governance, not just backup coverage.
A question worth separating out:
Q: How should organisations govern automation identities in recovery workflows?
A: Organisations should treat recovery automation as privileged access, not background tooling. That means bounding what backup jobs, orchestration agents, and scripts can change, then reviewing those permissions alongside the recovery design. If automation can trigger restores or alter operational settings, it needs explicit ownership, scoped permissions, and monitoring like any other high-value identity.
👉 Read our full editorial: Multi-cloud recovery gaps expose weak application-level resilience