Multi-Cloud Recovery That Actually Works

Cloud dovuto offrirci flessibilità, oltre a:

• Servizi di eccellenza.
• Innovazione Cloud.
• Nessuna dipendenza da un unico fornitore.

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 episodio.

.

• 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.

Il primo domino: l’isolamento

Each threat vector expands proportionally with environmental complexity. Multi-cloud doesn’t just diversify infrastructure – it expands operational aperture.

Backup a livello di servizio vs. Ripristino a livello di applicazione

Here’s where most organizations get caught.
They back up:

• Dati di Azure con Azure Backup
• Dati AWS con AWS Backup
• Cloud di Google Cloud con uno strumento separato

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.

Anteprima: PerchéCloud fallisce senza una mappatura delle dipendenze

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:

• Prestare la stessa attenzione all’RTO quanto all’RPO.
• Progettare tenendo contocloud .
• Migliorare la visibilità ove possibile.
• Ridurre la frammentazione dei fornitori e delle attività amministrative.
• Verifica del ripristino in diversi ambienti.

Recovery speed impacts revenue. Recovery clarity impacts reputation. Downtime impacts customer trust. Multi-cloud innovation must be matched by multi-cloud recovery discipline.

Il livello di intelligenza artificiale e automazione

Nessuna discussione è completa senza affrontare il tema dell’IA. I flussi di lavoro basati su agenti sono sempre più integrati nelle piattaforme SaaS aziendali. Ma l’automazione introduce nuove considerazioni:

• Di quali autorizzazioni dispongono gli agenti?
• Con quale frequenza vengono eseguiti i backup?
• Quali sono le implicazioni in termini di costi derivanti dalle decisioni relative all’automazione?
• Gli agenti vengono considerati come identità con accesso regolamentato?

AI can accelerate resilience – but without guardrails, it also can amplify risk. The key is controlled delegation.

Perché abbiamo avuto questa conversazione su 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.

Guarda l’episodio completo

In the full STRIVE episode, you’ll discover:

• Il vero divario tra il backup a livello di servizio e il ripristino a livello di applicazione.
• Perché l’isolamento è il primo tassello nella catena degli attacchi ransomware.
• In che modo la frammentazione dei fornitori complica l’orchestrazione.
• Su cosa devono trovare un accordo i CISO e i responsabili DevOps.
• Come l’intelligenza artificiale cambia l’equazione della resilienza.

Guardalo subito.
If you operate across AWS, Azure, or Google Cloud – this conversation is essential.

Domande frequenti

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.

D: Qual è la principale lacuna nelcloud ?

R: Il divario tra il modo in cui vengono eseguiti i backup (per singolo servizio) e il modo in cui deve avvenire il ripristino (a livello di applicazione).

Q: What does “environmental aperture” mean?

R: Si riferisce alla varietà di account, cloud, identità e servizi presenti in un ambiente. Man mano che tale varietà aumenta, il rischio e la complessità crescono in modo proporzionale.

D: Perché la mappatura delle dipendenze è fondamentale?

R: Le applicazioni si estendono ormai su più cloud e team. Senza una mappatura delle dipendenze dei servizi, la sequenza di ripristino diventa una questione di congetture.

D: In che modo l’intelligenza artificiale influisce sul ripristino di emergenza?

R: I flussi di lavoro basati sull’intelligenza artificiale possono aiutare ad automatizzare le decisioni relative al backup e al ripristino, ma richiedono rigorosi controlli degli accessi, una gestione dei costi e un’adeguata supervisione.

D: Da dove dovrebbero iniziare le organizzazioni per migliorarecloud ?

A: Inizia valutando:

• • Allineamento del ripristino a livello di applicazione.
  • Opportunità di consolidamento dei fornitori.
  • Sincronizzazione tra i team.
  • Strategia di isolamento in caso di incidenti.
  • Frequenzacloud .

Chris Mierzwa è direttore senior del reparto Portfolio Marketing presso Commvault.