Disaster Recovery
cloud leadspace
Disaster Recovery

Una panoramica sulla pianificazione della disaster recovery e indicazioni per determinare se Disaster-Recovery-as-a-Service (DRaaS) sia la scelta giusta per proteggere la tua azienda


Cos'è la disaster recovery?

La Disaster recovery (DR) si compone di tecnologie IT e best practice progettate per prevenire o ridurre al minimo la perdita di dati e l'interruzione delle attività derivanti da eventi catastrofici: guasti alle apparecchiature e interruzioni di corrente localizzate, attacchi informatici, emergenze civili, attacchi criminali o militari e disastri naturali.

Molte aziende, in particolare le organizzazioni di piccole e medie dimensioni, trascurano di sviluppare un piano affidabile e praticabile di disaster recovery. Senza un tale piano, tali aziende avranno una protezione minima dall'impatto di eventi bloccanti.

Il guasto dell'infrastruttura può costare fino a 100.000 USD all'ora e i costi di un errore critico delle applicazioni possono variare da 500.000 USD a 1 milione di USD all'ora. Molte aziende rischiano di non riprendersi da tali perdite. Oltre il 40% delle piccole imprese non riaprirà dopo aver subito un evento disastroso e, tra quelle che lo fanno, un ulteriore 25% fallirà entro un anno dalla crisi. La pianificazione della disaster recovery può ridurre drasticamente tali rischi.

La pianificazione della disaster recovery implica strategie, pianificazione, implementazione di tecnologie appropriate e continui test. Il mantenimento dei backup dei dati è una componente fondamentale della pianificazione della disaster recovery, ma un processo di backup e ripristino da solo non costituisce un piano completo di disaster recovery.

La disaster recovery richiede inoltre di prevedere la disponibilità di risorse di storage ed elaborazione tali da consentire il mantenimento di procedure solide di failover e failback. Failover è il processo di trasferimento dei carichi di lavoro ai sistemi di backup in modo che i processi di produzione e le esperienze degli utenti finali vengano interrotti il meno possibile. Failback  comporta il ritorno ai sistemi primari originari.

Consulta il nostro articolo per ulteriori informazioni sull' importante distinzione tra pianificazione del backup e della disaster recovery.


Pianificazione della Business continuity

La pianificazione della continuità operativa crea sistemi e processi per garantire che tutte le aree dell'azienda siano in grado di mantenere le operazioni essenziali o di riprenderle il più rapidamente possibile in caso di crisi o emergenza. La pianificazione della disaster recovery è un sottoinsieme della pianificazione della continuità operativa che si concentra sul ripristino dell'infrastruttura e dei sistemi IT.


Pianificazione della disaster recovery

Analisi dell'impatto aziendale


La creazione di un piano completo di disaster recovery inizia con l'analisi dell'impatto aziendale. Durante l'esecuzione di questa analisi, si creeranno una serie di scenari di emergenza dettagliati che potranno essere utilizzati per prevedere l'entità e la portata delle perdite che si subirebbero se determinati processi aziendali venissero interrotti. E se il call center del servizio clienti fosse distrutto da un incendio, ad esempio? O se un terremoto colpisse la sede centrale?

Ciò consentirà di identificare le aree e le funzioni aziendali più critiche e di determinare il tempo di inattività tollerabile da ciascuna di queste funzioni critiche. Partendo da queste informazioni, sarà possibile definire un piano che preveda come sarà possibile mantenere attive la maggior parte delle operazioni critiche in vari scenari.

La pianificazione della disaster recovery dell'IT deve essere dedotta dalla pianificazione della continuità aziendale e supportarla. Se, ad esempio, il piano di continuità aziendale richiede che i rappresentanti del servizio clienti lavorino da casa a seguito di un incendio del call center, quali tipi di hardware, software e risorse IT devono essere disponibili per supportare tale piano?

 

Analisi del rischio


Anche la valutazione della probabilità e delle potenziali conseguenze dei rischi che l'azienda dovrà affrontare è una componente essenziale della pianificazione della disaster recovery. Con il crescere degli attacchi informatici e dei ransomware, diventa fondamentale comprendere i rischi generali per la sicurezza informatica che tutte le aziende devono affrontare, nonché i rischi specifici legati al settore e alla posizione geografica.

Per una varietà di scenari, tra cui disastri naturali, guasti alle apparecchiature, minacce interne, sabotaggi ed errori dei dipendenti, è consigliabile valutare i rischi e considerare l'impatto complessivo sulla attività. È necessario domandarsi quanto segue:

  • Quali perdite finanziarie, legate a opportunità di vendita mancate o interruzioni delle attività fonte di entrate, si subirebbero?
  • A quali danni d'immagine andrebbe incontro il marchio dell'azienda? Come ne risentirebbe la soddisfazione del cliente?
  • Quale sarebbero le conseguenze sulla produttività dei dipendenti? Quante ore di lavoro potrebbero essere perse?
  • Quali rischi potrebbe comportare l'incidente per la salute o la sicurezza umana?
  • I progressi verso eventuali iniziative o obiettivi aziendali sarebbero influenzati? In che modo?

 

Assegnazione di priorità alle applicazioni


Non tutti i carichi di lavoro sono ugualmente critici per la capacità di un'azienda di mantenere i livello operativi e i tempi di inattività sono molto più tollerabili per alcune applicazioni rispetto ad altre. Suddividere i sistemi e le applicazioni in tre livelli, a seconda del loro tempo di inattività sopportabile e di quanto gravi sarebbero le conseguenze della perdita dei relativi dati.

  1. Mission-critical: Applicazioni il cui funzionamento è essenziale per la sopravvivenza dell'azienda.
  2. Importanti: Applicazioni per le quali è possibile tollerare periodi di inattività relativamente brevi.
  3. Non essenziali: Applicazioni che è possibile sostituire temporaneamente con processi manuali o di cui si può fare a meno.

 

Documentazione delle dipendenze


Il passaggio successivo nella pianificazione della disaster recovery consiste nella creazione di un inventario completo delle risorse hardware e software. In questa fase è essenziale comprendere le interdipendenze critiche delle applicazioni. Se un'applicazione software non funziona, quali altre ne saranno influenzate?

La progettazione di modelli di resilienza e di ripristino di emergenza nei sistemi è il modo migliore per gestire le interdipendenze tra le applicazioni. È fin troppo comune nelle odierne architetture basate su microservizi scoprire processi che non possono essere avviati quando altri sistemi o processi sono inattivi e viceversa. Questa è una situazione difficile da riprendersi ed è fondamentale scoprire tali problemi quando si ha tempo per sviluppare piani alternativi per i sistemi e i processi, prima che si verifichi un vero disastro.

 

Definizione degli RTO (recovery time objectives), RPO (recovery point objectives) e RCO (recovery consistency objectives)


Considerando le analisi del rischio e dell'impatto aziendale, si è in grado di stabilire definire gli obiettivi per il tempo necessario per ripristinare i sistemi, di quanti dati ci si può consentire di utilizzare e quanto danneggiamento dei dati o scarto è possibile tollerare.

L'RTO è il tempo massimo necessario per ripristinare il funzionamento dell'applicazione o del sistema a seguito di un'interruzione del servizio.

L'RPO rappresenta quanto indietro nel tempo bisogna andare nel recupero dei dati affinché l'azienda possa riprendere le normali operazioni. Per alcune aziende, perdere anche solo pochi minuti di dati può essere catastrofico, mentre quelle di altri settori potrebbero essere in grado di tollerare finestre più lunghe.

L'RCO viene definito nello SLA (service-level agreement) per i servizi di protezione continua dei dati. È una metrica che indica quante voci incoerenti nei dati aziendali provenienti da processi o sistemi ripristinati sono tollerabili in situazioni di disaster recovery, descrivendo l'integrità dei dati aziendali in ambienti applicativi complessi.

 

Problemi di conformità normativa


Tutti i software e le soluzioni di disaster recovery che un'azienda ha implementato devono soddisfare tutti i requisiti di protezione e sicurezza dei dati che si è obbligati a rispettare. Ciò significa che tutti i sistemi di backup e failover dei dati devono essere progettati per soddisfare gli stessi standard necessari per garantire la riservatezza e l'integrità dei dati dei sistemi primari.

Allo stesso tempo, diversi standard normativi stabiliscono che tutte le aziende devono implementate piani di disaster recovery e/o continuità operativa. Sarbanes-Oxley Act (SOX), ad esempio, richiede a tutte le aziende pubbliche negli Stati Uniti di conservare copie di tutti i documenti aziendali per un minimo di cinque anni. Il mancato rispetto di questa normativa (incluso il mancato rispetto di implementare e testare sistemi di backup dei dati appropriati) può comportare sanzioni pecuniarie significative per le aziende e persino il carcere per i dirigenti.

 

Scelta delle tecnologie


I backup fungono da base su cui costruire qualsiasi solido piano di disaster recovery. In passato, la maggior parte delle aziende si affidava a nastri e dischi fissi (HDD) per i backup, mantenendo più copie dei propri dati e archiviandone almeno una in una posizione esterna alla sede.

Nel mondo odierno in continua trasformazione digitale, i backup su nastro negli archivi fuori sede spesso non riescono a raggiungere gli obiettivi di RTO necessari per gestire le operazioni business-critical. La definizione dell'architettura della propria soluzione di disaster recovery implica la replica di molte delle funzionalità dell'ambiente di produzione e richiede l'assunzione di costi per il personale di supporto, l'amministrazione, le strutture e l'infrastruttura. Per questo motivo, molte organizzazioni si stanno rivolgendo a soluzioni di backup basate su cloud o a provider di Disaster-Recovery-as-a-Service (DRaaS) su vasta scala.

 

Scelta delle sedi di recupero


Costruire il proprio data center di disaster recovery comporta il bilanciamento di diversi obiettivi contrastanti. Da un lato, una copia dei dati dovrebbe essere archiviata in un luogo geograficamente abbastanza distante dalla propria sede centrale o dagli uffici tale da non essere interessato dagli stessi eventi sismici, minacce ambientali o altri pericoli del sito principale. D'altro canto, i backup archiviati fuori sede richiedono sempre più tempo per il ripristino rispetto a quelli che si trovano in locale nel sito primario e la latenza di rete può essere ancora maggiore su distanze maggiori.

 

Test e verifiche continuativi


In poche parole, se il piano di disaster recovery non è stato testato, non sarà possibile fare affidamento su di esso. Tutti i dipendenti con responsabilità pertinenti dovranno partecipare ai test della disaster recovery, che potranno includere, per un periodo di tempo, il mantenimento delle attività sul sito di failover.

Se l'esecuzione di test completi della disaster recovery non rientra nel budget o nelle capacità, è anche possibile pianificare una procedura dettagliata di "esercitazioni di simulazione" delle procedure di test, anche se bisogna essere consapevoli che questo tipo di test, rispetto a un test completo, ha meno probabilità di rivelare anomalie o punti deboli nelle procedure di disaster recovery, soprattutto la presenza di interdipendenze tra applicazioni sconosciute in precedenza.

Poiché le tue risorse hardware e software cambiano nel tempo, è necessario essere certi di aggiornare di conseguenza anche il piano di disaster recovery. È quindi consigliabile controllare e rivedere il piano periodicamente.

L'IBM Knowledge Center riporta un esempio di piano di disaster recovery.


DRaaS (Disaster Recovery as a Service)

Disaster-Recovery-as-a-Service (DRaaS) è una delle offerte di servizi IT gestiti più popolari e in rapida crescita ad oggi disponibili. Il tuo fornitore documenterà gli RTO e gli RPO in un SLA (service level agreement) che delinea i limiti per i tempi di inattività e le aspettative di ripristino delle applicazioni.

I fornitori DRaaS in genere forniscono ambienti di failover su cloud. Questo modello offre notevoli risparmi sui costi di mantenimento nel proprio data center delle risorse hardware dedicate e ridondanti. Sono disponibili formule in cui si paga una tariffa per il mantenimento delle funzionalità di failover più i costi per l'utilizzo delle risorse in una situazione di disaster recovery. In genere, il fornitore si assume tutte le responsabilità per la configurazione e la manutenzione dell'ambiente di failover.

Le offerte di servizi di disaster recovery variano da fornitore a fornitore. Alcuni fornitori definiscono la propria offerta sotto forma di soluzione completa e all-in-one, mentre altri offrono servizi frammentari che vanno dal ripristino di una singola applicazione alla replica completa del data center nel cloud. Alcune offerte possono includere servizi di pianificazione o test di disaster recovery, mentre altre addebiteranno un costo di consulenza aggiuntivo per questi servizi.

È bene assicurarsi che tutte le applicazioni software aziendali su cui si fa affidamento siano supportate, così come qualsiasi provider di cloud pubblico con si collabori. Sarà inoltre necessario assicurarsi che le prestazioni dell'applicazione siano soddisfacenti nell'ambiente di failover e che le procedure di failover e failback siano state ben testate.


Disaster recovery su Cloud

Se è stata già implementata una soluzione di disaster recovery (DR) on-premise, può essere difficile valutare i costi e i vantaggi della sua manutenzione rispetto al passaggio a un abbonamento DRaaS mensile.

La maggior parte delle soluzioni di DR on-premise incorre in costi per hardware, alimentazione, manodopera per manutenzione e amministrazione, software e connettività di rete. Oltre alle spese in conto capitale iniziali necessarie per la configurazione iniziale dell'ambiente di disaster recovery, sarà necessario prevedere un budget per gli aggiornamenti software regolari. Poiché la tua soluzione DR deve rimanere compatibile con l'ambiente di produzione principale, è consigliabile assicurarsi che la soluzione DR abbia le stesse versioni software. A seconda delle specifiche dell'accordo di licenza, ciò potrebbe effettivamente raddoppiare i costi del software.

Il passaggio a un abbonamento DRaaS non solo può ridurre le spese hardware e software, ma può anche ridurre i costi di manodopera spostando l'onere della manutenzione del sito di failover sul fornitore.

Se si sta prendendo in considerazione l'utilizzo di soluzioni DRaaS di terze parti, è bene assicurasi che il fornitore abbia la capacità di eseguire backup multisito tra regioni diverse. Se un evento meteorologico significativo come un uragano avesse un impatto sulla sede centrale, il sito di failover sarebbe abbastanza lontano da non essere interessato dalla tempesta? Inoltre, il fornitore avrebbe una capacità adeguata per soddisfare le esigenze combinate di tutti i suoi clienti nella tua zona se molti ne fossero colpiti contemporaneamente? Ci si affida ad un fornitore DRaaS per soddisfare gli RTO e gli RPO in tempi di crisi, quindi è necessario cercarne uno con una solida reputazione di affidabilità.

Leggi “Disaster Recovery as a Service (DRaaS) vs. Disaster Recovery (DR): Which Do You Need?” per una panoramica comparativa di entrambe le soluzioni.


Disaster recovery e IBM

Le soluzioni di disaster recovery su IBM Cloud sono resilienti e affidabili. È possibile eseguire il provisioning di un sito di failover in uno degli oltre 60 data center situati in sei regioni e in 18 zone di disponibilità globale, per assicurare una bassa latenza e per soddisfare requisiti aziendali specifici dell'area geografica.

Le soluzioni IBM disaster recovery offrono funzionalità di continuità aziendale di livello enterprise per implementazioni su cloud on-premise, pubblici, privati e ibridi. Le soluzioni sono progettate per supportare le architetture di disaster recovery da on-premises a IBM Cloud, da IBM Cloud a IBM Cloud e da provider cloud di terze parti a IBM Cloud. IBM offre anche consulenza sulla continuità aziendale per prevedere e pianificare un'ampia gamma di minacce, rischi e potenziali interruzioni dell'attività.

Inoltre, IBM ha stretto una partnership con Zerto per presentare Zerto on IBM Cloud, una soluzione di sisaster recovery semplice e scalabile che si installa perfettamente nell'ambiente VMware vSphere e offre RPO di secondi e RTO di minuti per tutte le macchine virtuali e i carichi di lavoro.

Sviluppa competenze attraverso corsi facoltativi di storage e resilienza, come "Panoramica sui concetti di ripristino di emergenza" e una varietà di altri corsi contenuti nella certificazione basata sui ruoli IBM Cloud Professional Architect.

Per ulteriori informazioni sulle soluzioni di disaster recovery su IBM Cloud e sulla licenza gratuita per Zerto on IBM Cloud, registrati oggi stesso per un account IBM Cloud gratuito.


Soluzioni correlate

Storage su nastro

Tecnologia di storage su nastro affidabile con protezione air-gap, conservazione a lungo termine, cyber-resiliente e con consumo efficiente di energia, ad un costo inferiore rispetto ad altri supporti.


Zerto on IBM Cloud

Raggiungi l'RPO (obiettivo del punto di ripristino) in pochi secondi e l'RTO (obiettivo del tempo di ripristino) in pochi minuti, con una soluzione di protezione dei dati facilmente implementabile e scalabile


Data center globali

Procedi in modo più fluido nel cloud e più sicuro sul campo con una maggiore scelta di opzioni di distribuzione per qualsiasi esigenza di carico di lavoro. La rete IBM® Cloud è resiliente, ridondante e altamente disponibile in 19 paesi su sei continenti.