Il Disaster Recovery (DR) è un argomento che, in molte aziende italiane, è sottovalutato. Spesso, quando parlo con i clienti di nuove infrastrutture o aggiornamenti, uno dei punti nella lista delle richieste è “prevedere la possibilità di DR”.

L’affermazione di cui sopra non significa nulla in se ma, in pratica, nel lessico dei clienti, è la possibilità di creare una infrastruttura che, in un futuro più o meno lontano (di solito nell’intorno del “mai”), possa essere replicata remotamente con l’auspicio di creare un sito di DR… ma anche questo, purtroppo, non significa nulla se non correttamente supportato da un piano per il Disaster Recovery che ne preveda il corretto utilizzo!

L’obiettivo di questa breve serie di articoli (qui il primo) è quindi quello di spiegare nel modo più semplice possibile alcuni aspetti di base del “recupero da disastri” e fare un po di luce in modo da fornire alcuni semplici strumenti e terminologie per una miglior valutazione sull’argomento.

una notizia locale

Mentre scrivo questo articolo mi è capitato questa notizia sotto mano: “Un incendio distrugge gli uffici della Motoparts (Minarelli)“… riporto cosa ha detto l’amministratore delegato dell’azienda: “Abbiamo perso tutti i dati che erano nei computer e sarà un bel problema ripartire in tempi brevi”. La produzione e i magazzini non sono stati intaccati dagli incendi ma l’azienda ha perso tutti i dati, gli ordini, gli archivi? ripartire? in bocca al lupo!

Quante volte capita di vedere scene del genere? quando le vedete vi domandate cosa sarebbe successo se quella ad incendiarsi fosse stata la vostra azienda?

una notizia mondiale

Non è il caso di continuare a speculare sulle tragedie ma anche in Giappone è successo un disastro, ben più grave e catastrofico di quello descritto sopra, l’economia nipponica è veramente in difficoltà ma sono sicuro che i Giapponesi ce la faranno (anche solo per il popolo che sono e la profonda cultura della sicurezza che hanno sempre avuto). In ogni caso è chiaro che partirà prima e meglio chi ha un serio piano di business continuity e disaster recovery mentre, nei casi più gravi, alcune aziende non riapriranno più oppure falliranno per la capacità di operare entro poco tempo in maniera efficiente.

una precisazione

Questa serie di articoli ha come argomento il ripristino da un disastro, esistono altre tematiche che sono attigue a questa e che riguardano quella che normalmente viene definita business continuity: mentre il DR ha come obiettivo ultimo quello di ripristinare la situazione a prima del disastro, la BC ha come obiettivo primario quello di garantire i servizi oggetto del business dell’azienda durante il verificarsi del disastro. Tutte queste tematiche, dovrebbero essere affrontate insieme ma già l’argomento DR è sicuramente molto ampio e non vorrei generare confusione in chi legge.

il Disaster Recovery Plan

E’ l’insieme di tutte le procedure, i documenti e le attività necessarie per ripristinare l’infrastruttura (non solo quella IT). In caso di un evento disastroso esistono diversi fattori di criticità che vanno considerati e il DRP ne deve tener conto, quindi deve essere:

  • recepito e condiviso da diverse persone (difficoltà di rintracciabilità delle risorse)
  • semplice, perchè c’è meno lucidità (durante le situazioni critiche aumenta fortemente lo stress)
  • redatto con cura (ogni elemento lasciato al caso sarà un potenziale rischio di fallimento del DRP)
  • deve essere verificato (è necessario implementare un processo di verifica ed eventuale correzione e scadenzato)

mantenere il DRP efficiente e aggiornato

Il DRP non è statico ma va verificato ed eventualmente aggiornato costantemente. L’infrastruttura evolve e non tenere conto del DR può significare non poter ripristinare la situazione nel caso sia necessario. Per questo motivo devono essere pianificate attività, scadenzate nel tempo, di verifica dell’intero processo con l’obiettivo di abbattere ogni rischio in caso di necessità. Le attività sono fra le più disparate e vanno dal ripristino di nastri di backup a campione, al far ripartire le applicazioni (con i relativi dati aggiornati) sul sito secondario per testarne l’operatività. Non tutti i piani di DR per l’IT sono uguali, la loro complessità è fortemente legata alla tipologia di business ed a quanto l’IT è pervasivo/critico in azienda e, in alcuni casi, alle normative vigenti. Le banche, gli istituti finanziari in genere e la Pubblica Amministrazione hanno degli obblighi precisi e normati, al contrario, le imprese private, sono più libere di valutare diversamente i costi/benefici del loro piano di DR.

definire le priorità

Non tutti i servizi sono uguali e non è detto che abbiano lo stesso valore per l’azienda e, in un momento di crisi, deve essere ben pianficata la lista delle attività di ripristino.

Di solito, è buona pratica, quella di suddividere i servizi IT in funzione della loro criticità in almeno tre livelli (indispensabili, importanti, secondari). La distinzione di cui ho accennato può aiutare molto a definire i livelli di servizio, i tempi di ripristino e le metodologie: un esempio pratico,  i  sistemi secondari potrebbero anche essere recuperati dai nastri del backup (opportunamente spostati in precedenza in una sede remota) anche giorni o settimane dopo l’effettivo recupero dei sistemi più importanti, abbattendo quindi i costi. Le metodologie per la copia remota dei dati e il successivo ripristino sono diverse ed hanno prerequisiti, difficoltà d’implementazione e costi diversi: avere l’accortezza di fare una buona analisi per dare la giusta priorità ad ogni servizio può sicuramente aiutare ad abbattere i costi e migliorare i tempi di recupero.

Gli argomenti del prossimo articolo saranno: RPO e RTO, limitare la necessità del DR, il sito di DR