Il DR (disaster recovery) si compone di tecnologie IT e best practice progettate per prevenire o ridurre al minimo la perdita di dati e l'interruzione dell'attività derivante 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 significativamente dirompenti.

Il guasto dell'infrastruttura può costare fino a 100.000 USD all'ora (link esterno a IBM) 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 aziende 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 del disaster recovery può ridurre drasticamente tali rischi.

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

Il 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. Il 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. Il failback comporta il ritorno ai sistemi primari originari.

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

La pianificazione della business continuity 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 del disaster recovery è un sottoinsieme della pianificazione della business continuity che si concentra sul ripristino dell'infrastruttura e dei sistemi IT.

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 per ciascuna di queste funzioni critiche. Partendo da queste informazioni, sarà possibile definire un piano che preveda come sarà possibile mantenere attiva la maggior parte delle operazioni critiche in vari scenari.

La pianificazione del disaster recovery dell'IT deve essere dedotta dalla pianificazione della business continuity aziendale e deve supportarla. Se, ad esempio, il piano di business continuity 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 del 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 sulle attività. È necessario domandarsi quanto segue:

• Quali perdite finanziarie, legate a opportunità di vendita mancate o interruzioni delle attività che generano profitti, 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 livelli operativi e i tempi di inattività sono molto più tollerabili per alcune applicazioni rispetto ad altre. Suddividi 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 del 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 disaster recovery 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 da cui è difficile 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 objective), RPO (recovery point objective) e RCO (recovery consistency objective)

Considerando le analisi del rischio e dell'impatto aziendale, dovresti essere in grado di stabilire gli obiettivi per il tempo necessario per ripristinare i sistemi, per la quantità di dati che puoi sopportare di utilizzare e per la quantità di danneggiamento o deviazione dei dati che puoi 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 implementare piani di disaster recovery e/o business continuity. Il 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 l'aver trascurato di stabilire e testare sistemi appropriati di backup dei dati) 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 un'ubicazione offsite.

Nel mondo odierno in continua trasformazione digitale, i backup su nastro negli archivi offsite 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 DRaaS (Disaster-Recovery-as-a-Service) su vasta scala.

Scelta delle ubicazioni dei siti di ripristino

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 da non essere interessato dagli stessi eventi sismici, minacce ambientali o altri pericoli del sito principale. D'altro canto, i backup archiviati offsite richiedono sempre più tempo per il ripristino rispetto a quelli che si trovano on-premise nel sito primario e la latenza di rete può essere ancora maggiore su distanze maggiori.

Test e verifiche continui

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 di disaster recovery, che potranno includere, per un periodo di tempo, il mantenimento delle attività sul sito di failover.

Se l'esecuzione di test completi di 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 offre un esempio di piano di disaster recovery.

DRaaS (Disaster-Recovery-as-a-Service) è una delle offerte di servizi IT gestiti più popolari e in rapida crescita oggi disponibili. Il tuo fornitore documenterà gli RTO e gli RPO in uno 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 basati sul cloud. Questo modello offre notevoli risparmi sui costi rispetto ad un modello che prevede la presenza di risorse hardware dedicate e ridondanti nel proprio data center. 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.

Assicurati che tutte le applicazioni software aziendali su cui fai affidamento siano supportate, così come qualsiasi provider di cloud pubblico con cui stai lavorando. Assicurati inoltre che le prestazioni dell'applicazione siano soddisfacenti nell'ambiente di failover e che le procedure di failover e failback siano state ben testate.

Se già hai implementato una soluzione di DR (disaster recovery) 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, dovrai prevedere un budget per gli aggiornamenti software regolari. Poiché la tua soluzione DR deve rimanere compatibile con l'ambiente di produzione principale, assicurati che la tua 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 stai valutando soluzioni DRaaS di terze parti, assicurati 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? Ti affidi 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?" (DRaaS (Disaster Recovery as a Service) e DR (disaster recovery) a confronto: di quale hai bisogno?) per una panoramica comparativa di entrambe le soluzioni.