Il Disaster Recovery, una soluzione per la Business Continuity

Il Disaster Recovery (o più brevemente DR) può essere definito come una delle possibili soluzioni per la continuità operativa a seguito di un disastro che può essere contemplata in un piano di Business Continuity. Come tale, la soluzione riguarda la garanzia di continuità del

business, anche in presenza di casi estremi, dove il disastro coincide con un evento catastrofico che ha come conseguenze la perdita permanente di dati, applicazioni e infrastrutture che reggono l’attività.

Il Disaster Recovery fornisce le procedure e l’infrastruttura tecnica per mantenere attivi i servizi critici in caso di indisponibilità della infrastruttura IT che li eroga. L’approccio è quindi di tipo reattivo, perchè le attività pianificate e le strutture vengono messe in atto a seguito dell’evento e non hanno natura preventiva ma risolutiva.

Un Disaster Recovery è implementato da un’organizzazione quando l’attività di business, si appoggia su dati, applicazioni e infrastrutture la cui perdita può compromettere l’intero business. Quando questi elementi vengono a mancare, è necessario che esistano strutture alternative su cui far ripartire le attività. L’obiettivo di un DR è quello di garantire la sopravvivenza del business e di pianificare come lo stesso debba permanere. La sopravvivenza del business è normalmente garantita da infrastrutture e applicazioni alternative.

Figura 4.1.1: fasi logiche del disastro e del ripristino di un CED su un sito alternativo. Fonte: CNIPA, Business continuity per la Pubblica Amministrazione, Ing. Gianfranco Pontevolpe

Nella Figura 4.1.1 si mostra un esempio di stadi logici che caratterizzano le fasi previste da un Disaster Recovery a partire dal disastro, e cioè lo studio di una soluzione, la preparazione di un sito di recovery e il recupero di dati perduti nell’incidente.

I sistemi di un’organizzazione possono consistere di applicazioni e dati più o meno critici in quanto detentori di un valore economico particolarmente importante. Solitamente la criticità dei sistemi, come visto in precedenza, viene determinata attraverso un’analisi dei rischi, precedente alla definizione della strategia e al Recovery Planning (si vedano in merito i capitoli 2 e 3).

Quando accade che un incidente rende indisponibili particolari servizi (si immagini una intera città o regione impossibilitata di effettuare chiamate telefoniche in quanto l’operatore non è disponibile), l’organizzazione richiede non solo il ripristino della attività cessata, ma anche che il tempo, in cui il tutto viene riesumato, sia incluso entro un definito arco. Il tempo è un fattore di estrema importanza, quando si tratta di far ripartire le normali attività. Quando l’azienda è in stato di fermo subisce delle perdite economiche ogni minuto, per cui si capisce bene come sia importante riprendere le attività in un tempo immediato.

Quanto appena detto introduce due aspetti importantissimi del Disaster Recovery, ovvero il

Recovery Time Objective e il Recovery Point Objective, che come vedremo diventano fattori

estremamente vincolanti nella definizione di un DR.

L’RTO (Recovery Time Objective) viene definito come il tempo massimo tollerabile per il pieno recupero dell'operatività di un sistema, a seguito dell’avvenimento di un disastro: è il tempo che intercorre fra l’evento disastroso e quello in cui viene ripristinato il sistema.

È necessario, che l’RTO sia fissato a seguito della analisi di tipo Business Impact. Se invece, per motivi diversi, a livello “Corporate” (dunque a livello direzionale), non è stata richiesta un’opportuna analisi BIA, l’RTO viene definito in funzione della criticità del sistema applicativo considerato (DR minimale), tenendo conto delle linee guida descritte all’interno del DR Plan del datacenter.

Figura 4.1.1: la freccia temporale che indica il tempo intercorrente tra il momento del disastro e quello in cui il sistema viene completamente ripristinato

L’RPO (Recovery Point Objective ) rappresenta il periodo di tempo massimo che può intercorrere tra l'ultimo salvataggio dati e il momento di blocco del processo. Fornisce una misura della massima quantità di dati che il sistema può perdere a causa di un evento di disastro. Tali dati sono appunto quelli prodotti nel periodo successivo a quello dell’ultimo backup e di cui non è stata mantenuta una copia di salvataggio.

Figura 4.1.2 : la freccia temporale indica il tempo intercorrente tra il momento in cui viene effettuato l’ultimo backup e l’evento disastroso.

Solitamente RTO e RPO sono stimati in termini di tempo, dunque ore, giorni o, in casi meno importanti, mesi. Sono due elementi di peso nella definizione della strategia, in quanto definiscono delle soglie di tempo, sia per il ripristino che per il salvataggio, da spendere per il

Momento del DIsastro Sistema fuori servizio Sistema ripristinato ed operazionale Recovery Time(RT)

Punto ultimo in cui il dato è in uno stato valido

Periodo di

data lost Momento del _disastro

Recovery Point(RP)

compatibili con le soglie di RTO e RPO richieste dai requisiti, stabiliti in base alla criticità dei sistemi in esame.

Nella definizione di una soluzione di Disaster Recovery risulta essenziale che vengano considerati altri due aspetti importanti: i livelli possibili di disastro, la criticità dei sistemi e delle applicazioni.

La classificazione della criticità dei sistemi prevede che siano individuate quattro possibili categorie, in base all’importanza delle attività svolte da ognuno di essi. I sistemi possono essere classificati secondo le definizioni seguenti:

Critici Sono sistemi per i quali le funzioni relative non possono essere sostituite facilmente, neanche con mezzi uguali. Per questa categoria di sistemi, si ritiene che neanche i metodi alternativi manuali possano essere efficaci. Tra l’altro, in caso di interruzione, la tolleranza sul tempo di fermo risulta essere estremamente bassa, per cui il costo stimato è, conseguentemente, molto elevato.

Vitali Sono sistemi per cui le attività relative possono essere svolte anche manualmente, se per un breve periodo di tempo. Un’interruzione di questi sistemi è maggiormente tollerata, rispetto al caso precedente, dunque anche il costo è minore. In generale, queste funzioni possono essere attivate entro pochi giorni: hanno infatti una riattivazione inclusa in un breve intervallo di tempo.

Delicati Sono sistemi per cui le funzioni possono essere svolte anche

manualmente e per i quali un interruzione è maggiormente tollerata, anche se per un certo periodo di tempo. Questo non significa tuttavia che il loro ripristino non debba essere eseguito, in quanto le attività compiute da questi sistemi sono comunque molto difficoltose, con un impegno elevato in termini di numero di risorse.

Non-critici Tali sistemi tollerano l’interruzione anche per un lungo periodo di tempo, con un costo molto basso, o quasi nullo, per l’azienda. Anche lo sforzo di riavvio risulta essere molto modesto.

Quando si valutano le applicazioni o i sistemi in base alla loro criticità devono essere tenuti da conto alcuni fattori. Innanzi tutto si deve tenere presente il periodo dell’anno in cui il disastro può accadere, in quanto la criticità delle applicazioni (software di sistema e dati) può variare in un certo arco di tempo: il servizio internet, ad esempio, è in media utilizzato maggiormente durante il periodo invernale, piuttosto che quello estivo, per cui un’assenza di disponibilità in quella stagione è tollerata meno.

Un piano d'emergenza deve prevedere il ripristino di tutte le funzioni aziendali e non solo del servizio ICT (Information and Communication Technology) centrale. Per la definizione del DRP (Disaster Recovery Plan), devono essere valutate le strategie di ripristino più opportune su:

siti alternativi;

metodi di back-up

sostituzione degli equipaggiamenti;

ruoli e responsabilità dei team.

Quando un servizio elaborativo risulta indisponibile per un periodo di tempo prolungato, a causa di un disastro imprevisto, si considera in genere l’eventualità di utilizzare una strategia di ripristino su un sito alternativo. Le strategie sono comunque diverse e variano da caso: verranno trattate meglio in seguito, in questo contesto si può dire che rientrano comunque nelle attività del management di un DR, dunque nella parte organizzativa-gestionale dell’azienda.