Notifications
Clear all
Topic starter
09/07/2026 5:49 pm
TL;DR: 42% of modern cloud application outages cannot be fixed with a simple backup restore and 78% of organisations need more than a month to restore complete environments, with average rebuild labour costs reaching $210,836 annually, according to Commvault research. Manual recovery is no longer compatible with cloud-native complexity, configuration drift, and multi-cloud fragmentation.
NHIMG editorial — based on content published by Commvault: The Hidden Cost of Cloud Complexity and Automatic Rebuilds
By the numbers:
- 90% of surveyed organizations use two or more cloud providers, according to Commvault’s ESG research.
- 47% of all new application development is now cloud-native, according to Commvault’s ESG research.
Questions worth separating out
Q: What breaks when cloud-native recovery depends on manual rebuilds?
A: Manual rebuilds break when teams cannot reliably recreate the same configuration, access, and trust relationships that existed before failure.
Q: Why do multi-cloud environments make recovery harder to govern?
A: Multi-cloud environments multiply the number of identity models, automation paths, and policy differences that recovery teams must coordinate.
Q: How do you know if configuration drift is undermining resilience?
A: You know drift is undermining resilience when rebuilds require manual fixes, environment recreation takes longer than expected, or restored services do not match the pre-failure baseline.
Practitioner guidance
- Map recovery-critical identities Identify every service account, API key, certificate, and automation role needed to rebuild core applications, then classify them by recovery dependency and privilege level.
- Standardise rebuild permissions across clouds Align the permissions required for recovery workflows in each cloud so rebuild automation does not depend on environment-specific manual exceptions.
- Version-control configuration and access state Store infrastructure definitions, access policies, and secret references in a controlled release process so the rebuild target matches the intended baseline.
What's in the full article
Commvault's full article covers the operational detail this post intentionally leaves for the source:
- The survey methodology behind the 40.6 person-day rebuild figure and the labour cost calculation.
- The practical mechanics of Cloud Rewind and the recovery workflow it is designed to support.
- The webinar discussion with the report author and Commvault speakers on cloud resilience operations.
- The business impact breakdown behind revenue loss, customer churn, and staff stress during rebuild events.
👉 Read Commvault's analysis of the hidden cost of cloud complexity and rebuilds →
Cloud application rebuilds: what is breaking resilience planning?
Explore further
09/07/2026 5:51 pm
Cloud resilience now depends on identity consistency as much as infrastructure automation. This article shows that rebuilds fail when teams cannot recreate the same access, configuration, and trust relationships that existed before the outage. In cloud-native estates, service accounts, secrets, certificates, and privileged automation paths are part of the recovery surface, not just the control plane. Practitioners should treat identity governance as a resilience dependency, not a separate IAM programme.
A question worth separating out:
Q: Who is accountable when recovery workflows fail during an outage?
A: Accountability should sit with the teams that own application configuration, cloud platform controls, and identity governance together, because rebuild failure usually crosses all three domains. If service identities, privileged automation, and recovery permissions are not defined before the outage, no single team can restore the service cleanly.
👉 Read our full editorial: Cloud application rebuilds are becoming a costly resilience tax
