Cos'è il cloud disaster recovery?

Il cloud disaster recovery mira a minimizzare i tempi di inattività e a ridurre l'impatto che crisi come guasti di sistema, disastri naturali o attacchi informatici possono avere su un'organizzazione.

Esistono diverse strategie che un'organizzazione può utilizzare per distribuire il cloud disaster recovery, ma tutte sono progettate per garantire la resilienza aziendale di fronte al caos. Secondo il report Cost of a Data Breach del 2026 di IBM, il costo medio globale di una violazione è di 4,99 milioni di dollari, con una media di 11,5 milioni di dollari negli Stati Uniti. I tempi di inattività costano alle organizzazioni circa 1.100 dollari all'ora durante l'evento e possono causare danni alla reputazione e perdite di affari futuri. Il cloud disaster recovery può aiutare a mitigare alcuni di questi rischi.

Si differenzia dalle tradizionali strategie di disaster recovery in quanto utilizza un'infrastruttura basata su cloud anziché un data center fisico. Una soluzione di disaster recovery basata su cloud può offrire alcuni vantaggi fondamentali, tra cui maggiore flessibilità e scalabilità rispetto a un backup, riduzione dell'investimento iniziale e protezione contro i guasti del sito.

Le due metriche più importanti in qualsiasi programma di disaster recovery sono l'obiettivo del punto di ripristino (RPO, Recovery Point Objective) e l'obiettivo del tempo di ripristino (RTO, Recovery Time Objective). Insieme, queste metriche vengono utilizzate per progettare e misurare l'efficacia di una strategia di cloud disaster recovery. 

Tipicamente, una grande organizzazione utilizza una strategia a più livelli in cui diversi tipi di dati hanno obiettivi differenti per RPO e RTO. Le organizzazioni potrebbero utilizzare un'analisi dell'impatto aziendale (BIA) per determinare gli obiettivi per diversi dipartimenti e tipi di dati.

L'RPO esprime la massima quantità di perdita di dati che un'organizzazione può tollerare. Viene utilizzato per decidere la frequenza con cui replicare dati come file, database e applicazioni e viene quindi misurato nel tempo. Se l'RPO è impostato su un'ora, significa che il sistema aggiorna i backup una volta all'ora e, a sua volta, può perdere un massimo di un'ora di nuovi dati. È un po' come un salvataggio automatico in un documento o in un gioco: più piccolo è l'RPO, meno progressi perdi.

L'RPO diventa più costoso man mano che diminuisce, a causa della maggiore frequenza di caricamento dei dati. Fortunatamente, gli obiettivi RPO molto bassi, che vanno da un minuto a pochi secondi, non sono necessari per tutte le operazioni di cloud disaster recovery. 

Ad esempio, mentre una grande operazione di e-commerce potrebbe richiedere un RPO molto basso per garantire che i dati di vendita siano aggiornati, la stessa operazione potrebbe richiedere solo un RPO di 24 ore per altri dati, come i file del personale o gli archivi di analytics. Questi esempi RPO più lunghi non richiedono una larghezza di banda di rete significativa o connessioni ultraveloci e sono quindi meno costosi. 

Alcuni software di cloud DR includono meccanismi di recupero puntuale, che trasmettono continuamente micro modifiche nei dati verso una voce di registro in corso e in scadenza. Questo permette all'organizzazione di tornare indietro al secondo poco prima che si verificasse un disastro.

La scelta di un sistema basato su cloud consente alle organizzazioni di utilizzare al meglio questa flessibilità: le organizzazioni possono eseguire un RPO quasi zero per i dati critici, sfruttando anche una replica più economica e più lunga per gli archivi, il tutto senza preoccuparsi dell'overprovisioning. Questa flessibilità offre efficienza e risparmio sui costi. 

L'RTO definisce il tempo massimo accettabile in cui un sistema o un processo può rimanere offline dopo un'interruzione, prima che il tempo di inattività causi danni inaccettabili. Si tratta del lasso di tempo che intercorre tra il momento in cui si verifica un disastro e il momento in cui l'attività commerciale è pienamente operativa. Sebbene sia l'RPO che l'RTO siano misurati in termini di tempo, ad esempio minuti, ore o giorni, l'RPO rappresenta un obiettivo per la massima perdita di dati, mentre l'RTO è l'obiettivo per il tempo di inattività.

"Attivo e funzionante" non è necessariamente così chiaro come sembra. Il semplice riavvio dell'hardware non dovrebbe essere l'indicatore della fine della misurazione dell'RTO. Diversi punti di controllo devono essere superati prima che l'attività venga completamente ripristinata per l'utilizzo da parte dei clienti: oltre al riavvio hardware, i servizi backend, l'instradamento di rete e il DNS devono essere tutti operativi. 

Il cloud disaster recovery può contribuire a ridurre l'RTO esternalizzando una parte significativa delle attività di ripristino a fornitori dedicati. In una configurazione di disaster recovery on-premise, gli ingegneri potrebbero dover entrare fisicamente in un edificio e riavviare o sostituire manualmente l'hardware: non è così con il cloud DR. La scalabilità istantanea significa che tutti i nuovi server o storage necessari sono disponibili ogni volta che è necessario. 

Sebbene il cloud disaster recovery riduca l'RTO durante il ripristino, l'RTO ottenibile dipende ancora da fattori come il volume dei dati, il metodo di replica e il modo in cui è costruito il sistema di failover (ad esempio, se si tratta di uno standby a caldo o se tutto deve essere avviato a freddo. ) Queste strategie saranno approfondite nella sezione successiva. 

Esistono quattro strategie principali utilizzate nel cloud disaster recovery, che variano in base all'utilizzo della larghezza di banda, ai requisiti di velocità e agli obiettivi di RPO e RTO.

La strategia di disaster recovery più semplice nel cloud, ovvero il backup e il ripristino, funziona creando una copia di base delle immagini del server, dei file e di altri dati e salvandola periodicamente nel cloud. Se si verifica un disastro, gli script di automazione ripristinano dai backup e avviano i server operativi.

I backup possono essere mutabili o immutabili, questi ultimi hanno una protezione da scrittura in modo che non possano essere modificati, eliminati o sovrascritti. I backup immutabili sono particolarmente utili per proteggersi dai ransomware, poiché non possono essere modificati. La strategia di backup e ripristino in genere comporta sia un RTO che un RPO più elevati rispetto ad altre strategie.

L'RTO per un sistema di backup e ripristino è elevato perché nessuna infrastruttura informatica è ancora in esecuzione: questo sistema memorizza semplicemente i dati per la ricostituzione in un secondo momento. Tale ripristino può comportare la copia di ingenti quantità di dati su nuovi server e potrebbe richiedere complesse attività di provisioning, routing e indicizzazione per essere pienamente operativo.

Anche l'RPO per un sistema di backup e ripristino è elevato perché i backup vengono acquisiti periodicamente anziché continuamente. I dati acquisiti nell'intervallo tra i backup sono i dati persi. Questi sistemi spesso si basano sullo storage a freddo, in cui i dati vengono scritti su hardware come dischi rigidi (HDD) o nastri magnetici, che vengono poi spenti. Questo è conveniente dal punto di vista economico perché richiede poca energia o larghezza di banda per lunghi periodi di tempo, ma far girare quei dischi per recuperare i dati può essere un processo lento, il che aumenta l'RTO.

La strategia della fiamma pilota prende il nome dalla fiamma pilota in una caldaia a gas, uno scaldabagno o un camino: una piccola fiamma che consuma il minor combustibile possibile e consente comunque l'accensione istantanea. Nel contesto del cloud disaster recovery, la strategia della fiamma pilota prevede di mantenere attivo un elemento, tipicamente un database replica che si aggiorna continuamente con qualsiasi modifica al database primario. 

Altri elementi, incluse immagini di applicazioni e server web e modelli di container, si trovano nello storage cloud più economico, talvolta chiamato warm storage. Il warm storage si riferisce a un livello di storage (che ha nomi diversi a seconda del provider) il cui prezzo è calcolato per accessi poco frequenti ma immediati. È più economico che mantenere questi elementi costantemente aggiornati, ma è comunque accessibile molto rapidamente, a differenza del cold storage e del suo recupero più lento.

Immagini e template vengono tipicamente aggiornati solo quando vengono apportate modifiche al codice sottostante. Quando si verifica un disastro, il provider di cloud può avviare rapidamente nuovi server e collegarli al database, riducendo al minimo i tempi di inattività.

La strategia della fiamma pilota sfrutta i prezzi più bassi dei livelli di storage a cui si accede raramente, mantenendo il database attivo e in continuo aggiornamento: spesso una soluzione ideale di “compromesso” per molte organizzazioni.

Il warm standby è un passo avanti rispetto alla strategia della fiamma pilota in termini di costi e RTO. Mentre la strategia della fiamma pilota mantiene i server delle applicazioni come immagini che possono essere ricostruite, una configurazione warm standby esegue continuamente quei server, solo di dimensioni inferiori, per risparmiare energia e costi.

Un modo per interpretare questo è che nella strategia della fiamma pilota il disaster recovery utilizza istruzioni memorizzate per ricreare gli ambienti; nel warm standby, un'istanza di dimensioni ridotte è sempre disponibile per gestire il traffico, mentre altri server possono essere scalati in background. Queste istanze vengono in genere eseguite su macchine virtuali (VM), in sistemi sia warm che hot standby.

Scalare o espandere l'uso dei server esistenti è più veloce della creazione e dell'avvio di nuovi server perché la fase di ricostruzione viene rimossa. Ciò può ridurre l'RTO a pochi minuti, con un RPO vicino allo zero (perché un'istanza è sempre attiva). Tuttavia, queste cifre comportano un aumento dei costi. 

Il warm standby richiede anche ulteriori considerazioni per evitare il problema del "fiume in piena": un'enorme quantità di traffico che sovraccarica i server di standby più piccoli. I provider di cloud hanno diversi modi per affrontare questo problema, ad esempio scalare i server prima di spostare il traffico. Questo comporta un breve tempo di inattività iniziale ma protegge dall'eccessivo sovraccarico delle unità di elaborazione centrali (CPU).

L'hot standby utilizza due o più istanze simultanee in più posizioni fisiche, tutte in esecuzione. Come un motore a reazione, se un ambiente si guasta, gli ambienti funzionali rimanenti possono gestire il carico riparando il danno. In genere, le organizzazioni limitano il carico su ciascuna istanza in modo che ognuna abbia la capacità di gestire l'intera operazione qualora fosse l'unica istanza disponibile. 

L'hot standby è in genere abbinato a un altro tipo di sistema di backup: è un sistema progettato per mantenere un'elevata disponibilità in caso di situazioni come un guasto dell'hardware. Nel caso di attacchi malware che prendono di mira l'integrità dei dati, l'hot standby è inadeguato poiché tutti i dati sono contaminati. Pertanto, i sistemi di fiamma pilota, warm standby e hot standby sono generalmente associati a una forma di backup snapshot point-in-time. 

Sebbene il cloud DR, il cloud backup e il disaster recovery as a service (DRaaS) abbiano tutti obiettivi simili di protezione dei dati in caso di emergenza, differiscono in due aspetti: la quantità di ambiente e automazione inclusa nel backup e chi lo gestisce . 

Il backup su cloud è un termine generico che descrive una situazione in cui i dati vengono copiati nel cloud storage. Il backup su cloud mantiene una copia sicura di tutti questi dati, ma non include app, server o compute, il che significa che un team IT interno addetto al disaster recovery dovrà scaricare e ricostruire manualmente il sistema. 

Il cloud DR aggiunge automazione e orchestrazione al backup su cloud. Acquisisce l'intero ambiente applicativo e gli script e le regole di automazione utilizzati per fornire server, ripristinare dati e reindirizzare il traffico. Ciò consente il ripristino del sistema con uno sforzo manuale decisamente inferiore rispetto al backup su cloud, che offre funzionalità più limitate. 

DRaaS è essenzialmente una versione gestita da terze parti del cloud DR. Invece di creare i propri script e regole per la data replication e il failover, un'organizzazione può esternalizzare il lavoro a un provider DRaaS. Alcuni DRaaS si presentano sotto forma di dashboard self-service per il test e l'attivazione, mentre altre piattaforme DRaaS sono completamente gestite da una terza parte.

Il cloud disaster recovery è un segmento in rapida crescita: secondo H2Vantix, si prevede che l'industria cloud DR crescerà da 12,1 miliardi di dollari nel 2025 a 14,46 miliardi di dollari nel 2026. Le organizzazioni scelgono sempre più spesso sistemi completamente basati su cloud o hybrid cloud per il disaster recovery. Secondo Global Growth Insights, il 59% delle aziende ha migrato almeno parte della propria infrastruttura di recupero verso il cloud. Ci sono diversi motivi per cui il cloud disaster recovery è sempre più popolare.

Uno dei maggiori vantaggi del cloud disaster recovery rispetto alle tradizionali configurazioni di disaster recovery fisico è il risparmio sui costi iniziali. In una configurazione di disaster recovery tradizionale, il proprietario deve acquistare tutto l'hardware e l'installazione in anticipo, oltre alle utility e alla manutenzione. Il cloud disaster recovery consente a un'organizzazione di pagare solo per ciò che utilizza.

L'opinione comune sul calcolo generale è che, sebbene il cloud riduca la configurazione iniziale, i costi a lungo termine per workload prevedibili e ad alto volume spesso favoriscono soluzioni in loco. Questo perché l'investimento iniziale si ammortizza nel tempo trasformandosi in un costo fisso prevedibile, oltre alle tariffe per il trasferimento dei dati, agli abbonamenti e agli altri costi associati al cloud computing. Il caso è meno semplice per il disaster recovery e si riduce in realtà all'utilizzo e alla proprietà.

In molti casi, il costo totale di proprietà può anche essere inferiore a lungo termine per il disaster recovery, perché le risorse di DR rimangono inattive per la maggior parte del tempo e il cloud consente a un'organizzazione di evitare di pagare per possedere queste risorse se non ne possiede già. 

Tuttavia, se un'organizzazione dispone già di un secondo sito fisico e deve solo aggiungere il disaster recovery al carico, oppure esegue un workload stabile, ad alto volume e 24 ore su 24, abbastanza pesante da mantenere l'hardware sufficientemente utilizzato, il TCO potrebbe essere inferiore per un backup fisico.

La scalabilità può rappresentare un problema per il backup e il disaster recovery on-premise, poiché richiede l'acquisto di ulteriore storage o potenza di calcolo, oltre all'installazione e alla configurazione. Oltre alla spesa descritta sopra, questo richiede tempo. Con il cloud disaster recovery, la scalabilità è integrata e spesso automatizzata: lo storage e l'elaborazione possono scalare rapidamente in base alla domanda. 

Questa scalabilità può essere particolarmente vantaggiosa per le organizzazioni le cui esigenze di disaster recovery fluttuano. Questo problema è particolarmente evidente con l'hardware inutilizzato: se si possiede già l'hardware è molto difficile effettuare un downgrade per evitare di pagare per storage o potenza di calcolo non utilizzati. Si dovrebbero vendere i dispositivi usati e poi ricomprarli quando necessario, oppure semplicemente rassegnarsi a pagare per apparecchiature di cui non si ha bisogno. Evitare i costi dell'overprovisioning è uno dei principali motivi che spingono all'adozione del cloud DR.

La manutenzione di un'installazione di disaster recovery on-premise può essere una proposta rischiosa quando si tratta di disastri naturali. Un'alluvione, un incendio o un altro disastro naturale può essere devastante per l'infrastruttura IT on-premise, operando come un unico punto di guasto. Il disaster recovery in cloud consente a un'organizzazione di separare lo storage in diverse posizioni fisiche, tutte accessibili tramite una rete, proteggendo da guasti di singoli siti e contribuendo a mantenere la continuità aziendale.

Esistono diverse fasi comuni per l'implementazione iniziale, tra cui:

Un'analisi iniziale sia dei rischi che dell'impatto aziendale è un buon primo passo per stabilire di cosa l'organizzazione ha bisogno in termini di protezione dei dati. Ciò potrebbe significare stabilire metriche RTO e RPO target per diverse applicazioni, mappare tutte le dipendenze del sistema e classificare i dati in categorie di priorità per cold, warm o hot storage. 

La valutazione del rischio può comportare l'identificazione dei potenziali tipi di rischio (attacchi ransomware, furto di dati, disastri ambientali o errori umani, ad esempio). Ma ci sono altre valutazioni da fare. La dipendenza da un singolo fornitore è sempre un rischio nella scelta di un fornitore di servizi, cloud o di altro tipo, un fattore che può rendere un ambiente multi-cloud un investimento vantaggioso. Inoltre, potrebbero esserci normative che regolano lo storage di determinate informazioni sui cloud pubblici che devono essere prese in considerazione.

Una volta che un'organizzazione sa di cosa ha bisogno, può confrontare i modi per raggiungere quegli obiettivi. Le differenti strategie (backup e ripristino, fiamma pilota, warm standby e hot standby) possono essere utilizzate contemporaneamente per diverse categorie di disaster recovery. 

Se l'organizzazione ha optato per un sistema DRaaS, gran parte della configurazione e della gestione saranno gestite dal fornitore. In altri casi, l'organizzazione dovrà configurare i propri intervalli di sincronizzazione dei dati, l'orchestrazione del failover e le regole di storage. 

Il test e la manutenzione regolari di un sistema di DR cloud sono fondamentali per garantire che il sistema di DR cloud funzioni correttamente e sia preparato per gli scenari peggiori. Sia i team IT interni che i team di gestione DRaaS terzi possono regolarmente condurre test isolati per assicurarsi che tutto sia in ordine. 

Questi test possono misurare l'RTO e l'RPO, confermare che le applicazioni funzionano effettivamente dopo un disastro, garantire che il failover funzioni come previsto e possono anche fungere da prova generale per i team IT. Questa simulazione può anche essere utile per testare il failback, ovvero il processo di ritorno alle normali operazioni.