--- title: "Multi-Cloud Recovery That Actually Works | Blog | Commvault" type: "BlogPosting" language: "en" url: "https://www.commvault.com/blogs/multi-cloud-recovery-that-actually-works" date: "2026-04-24T09:00:26-04:00" modified: "2026-04-23T16:59:03-04:00" description: "Multi-cloud adoption isn’t slowing down. But unless recovery strategies evolve alongside architecture, complexity will outpace preparedness." image: "https://www.commvault.com/wp-content/uploads/2026/04/Thumbnail_Blog-Multicloud-Recovery-2026.png" authors: - name: "Chris Mierzwa" jobTitle: "Senior Director, Portfolio Marketing, Commvault" breadcrumbs: - name: "Commvault Home" url: "https://www.commvault.com/" - name: "Blogs" url: "https://www.commvault.com/blogs" - name: "Multi cloud recovery that actually works" --- # Multi-Cloud Recovery That Actually Works Multi-cloud was supposed to give us flexibility, along with: --- - Best-of-breed services. - Cloud-native innovation. - Freedom from vendor lock-in. --- But when a cyber incident hits, that flexibility often becomes complexity. --- In this episode of **STRIVE**, I sat down with Senior Director of Product Management Akshay Joshi – whose career spans IBM, AWS, Microsoft, Clumio, and now Commvault – to unpack one uncomfortable truth: Most organizations think they’re ready for multi-cloud recovery. --- Until they’re not. Watch the [full episode](https://www.readiverse.com/resources/video/strive-building-multi-cloud-recovery-that-actually-works). --- ## Key Takeaways: What Multi-Cloud Recovery Really Demands --- - **Backup at the service level doesn’t equal recovery at the application level.** Protecting individual data sources is not the same as restoring a synchronized application ecosystem. - **Recovery complexity multiplies across clouds.** Different recovery points, different accounts, different admin teams – each adds friction when time matters most. - **Native hyperscaler tools are necessary – but not sufficient.** They protect within their own cloud but don’t orchestrate across clouds. - **Isolation is the first domino in a cyber event.** The larger the environment’s aperture, the harder it is to contain impact. - **Resilience must be designed in – not retrofitted later.** Dependency mapping and recovery planning should begin at application design, not after deployment. - **AI-enabled automation adds power – and new risk.** Agentic workflows require tight permission controls and governance discipline. --- ## The Gap Between “On Paper” and Reality --- On paper, recovery seems simple: When do you recover to? What do you recover? Where do you recover it? --- But, as Akshay explains, each of those questions fractures in a multi-cloud world. Different services may have different recovery points. Some microservices may be impacted while others aren’t. Recovery may require re-architecting if restored cross-regionally or cross-account. --- What looks straightforward in documentation becomes deeply complex in execution. And when ransomware hits, teams don’t calmly reference playbooks – they scramble. --- ## The First Domino: Isolation --- Each threat vector expands proportionally with environmental complexity. Multi-cloud doesn’t just diversify infrastructure – it expands operational aperture. --- ## Service-Level Backup vs. Application-Level Recovery --- Here’s where most organizations get caught. --- They back up: --- - Azure data with Azure Backup - AWS data with AWS Backup - Google Cloud data with a separate tool --- Individually, each service may be protected. Collectively, the application may not be recoverable in a synchronized state. --- Native tools don’t communicate across clouds. They aren’t inherently multi-cloud in orchestration. They aren’t tuned to optimize recovery time objective (RTO) or recovery point objective (RPO) at scale for cross-cloud architectures. --- And when recovery depends on aligning multiple data sources across hyperscalers, orchestration becomes the difference between hours and days. This is exactly why unified recovery strategies exist – not to replace hyperscalers, but to coordinate them. --- ## Dependency Mapping Isn’t Optional Anymore --- We’ve been talking about application dependency mapping for more than a decade. But in a multi-cloud world, it’s no longer a “nice to have.” Applications now span multiple hyperscalers, multiple DevOps teams, multiple admin domains, and multiple vendor backup tools. --- Fragmented ownership slows recovery. Vendor fragmentation complicates orchestration. Operational silos create delays at the worst possible time. Resilience must be operationalized from the beginning – not bolted on after deployment. --- ## Sneak Peek: Why Multi-Cloud Recovery Fails Without Dependency Mapping --- --- In this moment from the STRIVE conversation, Akshay explains why operationalizing resilience at the architecture stage is critical for surviving real-world cyber events. --- ## Designing for Recovery – Not Just Protection --- One of the most powerful points in this episode: Modern applications should be designed not only around performance and scale – but around recoverability. That means: --- - Thinking about RTO as much as RPO. - Architecting with cross-cloud orchestration in mind. - Consolidating visibility where possible. - Reducing vendor and admin fragmentation. - Testing recovery across environments. --- Recovery speed impacts revenue. Recovery clarity impacts reputation. Downtime impacts customer trust. Multi-cloud innovation must be matched by multi-cloud recovery discipline. --- ## The AI and Automation Layer --- No discussion is complete without addressing AI. Agentic workflows are increasingly embedded in enterprise SaaS platforms. But automation introduces new considerations: --- - What permissions do agents have? - How frequently are backups being triggered? - What cost implications arise from automation decisions? - Are agents treated as identities with governed access? --- AI can accelerate resilience – but without guardrails, it also can amplify risk. The key is controlled delegation. --- ## Why We Had This Conversation on STRIVE --- STRIVE isn’t about repeating what everyone already knows. It’s about confronting the gaps that surface during real-world cyber events. Multi-cloud adoption isn’t slowing down. But unless recovery strategies evolve alongside architecture, complexity will outpace preparedness. --- That’s why this discussion matters. And that’s why we brought Akshay in – someone who’s operated across hyperscalers and understands both their power and their limitations. --- ## Watch the Full Episode --- In the full STRIVE episode, you’ll discover: --- - The real gap between service-level backup and application-level recovery. - Why isolation is the first domino in ransomware events. - How vendor fragmentation complicates orchestration. - What CISOs and DevOps leaders must align on. - How AI changes the resilience equation. --- [Watch now](https://www.readiverse.com/resources/video/strive-building-multi-cloud-recovery-that-actually-works). --- If you operate across AWS, Azure, or Google Cloud – this conversation is essential. --- ## FAQs --- **Q: Why isn’t native hyperscaler backup enough?** --- **A:** Native tools protect data within a specific cloud but don’t orchestrate recovery across clouds. Multi-cloud applications require coordinated restoration across services and providers. --- **Q: What is the biggest gap in multi-cloud recovery?** --- **A:** The disconnect between how backups are made (service-by-service) and how recovery must happen (application-wide). --- **Q: What does “environmental aperture” mean?** --- **A:** It refers to the breadth of accounts, clouds, identities, and services in an environment. As aperture expands, risk and complexity increase proportionally. --- **Q: Why is dependency mapping critical?** --- **A:** Applications now span multiple clouds and teams. Without mapping service dependencies, recovery sequencing becomes guesswork. --- **Q: How does AI impact disaster recovery?** --- **A:** AI-enabled workflows can help automate backup and recovery decisions but require strong access controls, cost governance, and oversight. --- **Q: Where should organizations start improving multi-cloud recovery?** --- **A:** Begin by evaluating: --- - - Application-level recovery alignment. - Vendor consolidation opportunities. - Cross-team synchronization. - Isolation strategy during incidents. - Cross-cloud testing frequency. --- [*Chris Mierzwa*](https://www.linkedin.com/in/cmierzwa/) *is Senior Director, Portfolio Marketing, at Commvault.*