All’inizio di questo mese, Google Cloud ha rivelato di aver accidentalmente cancellato l’account del suo cliente UniSuper, un fondo pensione australiano da 125 miliardi di dollari.
Secondo una dichiarazione congiunta di Google Cloud e UniSuper, la cancellazione è avvenuta a causa di una “involontaria configurazione errata”. Di conseguenza, più di 600.000 utenti del fondo pensione non hanno potuto accedere ai loro account per oltre una settimana.
Secondo la dichiarazione, UniSuper aveva integrato la ridondanza geografica nel suo ambiente Google Cloud. Tuttavia, la configurazione errata ha causato l’eliminazione dei dati del fondo in entrambe le sedi.

Il fondo è riuscito a ripristinare i dati e i servizi tramite un fornitore di backup di terze parti non nominato. Tuttavia, non è stato facile. Il ripristino dell’istanza Google Cloud di UniSuper ha richiesto “un’incredibile quantità di concentrazione, sforzi e collaborazione tra i nostri team per consentire un ampio recupero di tutti i sistemi principali”, secondo la dichiarazione.

Principali risultati:

• L’infrastruttura cloud come servizio (IaaS) non elimina la necessità di backup.
• La geo-ridondanza non elimina la necessità di backup.
• C’è un motivo per cui i fornitori di cloud pubblico come Google e Amazon raccomandano la protezione dei dati da parte di terzi nei loro contratti con gli utenti. Non puntate tutto su un unico paniere.
• Con l’aumento dell’adozione degli IaaS, molte organizzazioni avranno bisogno di competenze specifiche per il backup e il disaster recovery.

Quindi, cosa è successo?

Secondo la dichiarazione, “l’interruzione è stata causata da una sequenza di eventi senza precedenti, in cui un’involontaria configurazione errata durante il provisioning dei servizi Private Cloud di UniSuper ha portato alla cancellazione dell’abbonamento Private Cloud di UniSuper”.

Come già detto, UniSuper aveva una ridondanza di dati in due aree geografiche, ma poiché l’abbonamento del fondo è stato terminato, i dati sono stati cancellati in entrambe. La dichiarazione congiunta indica che si è trattato di un evento isolato e che Google Cloud ha adottato misure per garantire che non si ripeta.

Backup 3-2-1 in IaaS

La strategia di backup dei dati 3-2-1 è un metodo noto e affidabile per proteggersi dalla perdita di dati.

Il principio è semplice: mantenere tre copie dei dati, conservarne due su diversi tipi di supporti e mantenerne una in un luogo geograficamente diverso per il ripristino di emergenza.

Il concetto esiste fin dai tempi dei backup su nastro. All’epoca, significava dati di produzione, backup su disco o su nastro in loco e nastro fuori sede per il ripristino di emergenza. In un ambiente IaaS (Infrastructure as a Service), la strategia di backup 3-2-1 mantiene questi principi fondamentali.

Tuttavia, la strategia può essere implementata in modi diversi e l’approccio adottato può avere un impatto significativo sulla capacità di soddisfare gli obiettivi di tempo di ripristino (RTO). Questo è evidente nella situazione di UniSuper.
Secondo la dichiarazione, UniSuper aveva tre copie di dati:

• I dati live nell’ambiente Google Cloud di UniSuper.
• La copia secondaria ridondante, anch’essa in Google Cloud.
• Il backup di terze parti da cui è stato effettuato il ripristino.

Inoltre, disponeva di due “supporti” diversi (in questo caso i provider: Google Cloud e il backup di terze parti) e di uno “fuori sede” (il backup di terze parti in quanto esterno a Google Cloud).
Per molte organizzazioni, questa potrebbe essere una soluzione adeguata, soprattutto se il fornitore di backup offre funzionalità di business continuity che consentono un rapido ripristino di applicazioni e servizi mission-critical. Quindi, cosa è andato storto?
Il ripristino di un set di dati di grandi dimensioni in un ambiente operativo complesso (server virtuali, cloud storage, database, ecc.) può richiedere molto tempo. Per questo motivo, le organizzazioni con una tolleranza estremamente limitata per i tempi di inattività delle applicazioni (come ad esempio un super fondo con 125 miliardi di dollari in gestione) richiedono probabilmente una soluzione che fornisca sia ridondanza che disponibilità.
Alcune organizzazioni ottengono questo risultato replicando i carichi di lavoro su un secondo provider IaaS. In altre parole, se i dati e le applicazioni primarie sono in Google Cloud, la copia secondaria (di failover) risiederebbe in AWS o Microsoft Azure. Il backup di terze parti rimarrebbe per fornire ripristini rapidi di file e cartelle, resilienza ai ransomware, conformità e così via.

Il diavolo sta nei dettagli.

Necessaria competenza in materia di DR

Ricordate che si tratta di un fondo con centinaia di miliardi di dollari in gestione. Se UniSuper può beneficiare di ulteriori competenze in materia di DR, anche la PMI media può farlo. Ecco perché il disaster recovery as a service (DRaaS) è un’offerta redditizia per molti fornitori di servizi gestiti (MSP).

Crediamo che il DRaaS rappresenti un’enorme opportunità per i partner Cove. Ecco perché abbiamo aggiunto e continuiamo ad aggiornare Cove Continuity, le nostre funzionalità di continuità aziendale basate sulla virtualizzazione. Recentemente abbiamo aggiunto Standby Image per VMware ESXi, un modo più efficiente per gli MSP di fornire DRaaS agli utenti VMware.