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 e qui i primi due) è 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.

RPO e RTO

RPO (recovery point objective) e RTO (recovery time objective) sono sicuramente i due termini più utilizzati quando si parla di DR da un punto di vista pratico. Infatti, l’ultimo punto dell’articolo precedente, riguardava la definizione delle priorità nel ripristino dei diversi servizi in un piano di DR, l’RPO e l’RTO sono i due parametri che ci aiutano a misurare questa priorità.

RPO: definisce il primo punto di consistenza utile indietro nel tempo per recuperare un dato, in pratica quanto devo tornare indietro per avere la certezza di un dato ripristinabile (un backup, una snapshot, ecc.)

RTO: è il tempo necessario per ripristinare il servizio.

E’ ovvio quindi che RPO e RTO sono due metriche fondamentali che definiscono con chiarezza quanto è critico un servizio per l’azienda e quanti dati ci si può permettere di perdere in caso di disastro. Un esempio: nel caso di un RPO di 4 ore e un RTO di 8 ore potrei ragionevolmente aspettarmi che, nell’evenienza di un disastro alle ore 12 e nella peggiore delle ipotesi, dovrei essere in grado di ripristinare il servizio entro le 20 con i dati salvati alle 8 di mattina. Non c’è dubbio quindi che, nella maggioranza dei casi, RPO/RTO stringenti significano costi elevati mentre, al contrario, più sono ampi e più sarà economico il ripristino della situazione.

Nel mondo reale RTO/RPO tendenti allo 0 significano repliche di dati sincrone a livello storage (al massimo livello di servizio si affianca automaticamente il prezzo più alto in assoluto). Questa pratica è in uso negli istituti finanziari, aereoporti, telco, ecc. dove perdere anche una sola transazione può pregiudicare la vita (o più semplicemente il denaro) di qualcuno. Al contrario, mi capita spesso, ancora oggi, di avere a che fare con piani di DR che prevedono l’uso di nastri per il ripristino con costi avvicinabili da ogni azienda che voglia implementare un primo livello di DR.

i siti per il DR

Nel primo articolo di questa serie avevo già introdotto questo argomento: la prima regola che è necessario darsi quando si pensa a questa eventualità è quella di cercare di stare lontano dal potenziale disastro.
Per quanto riguarda la locazione fisica è sempre bene minimizzare i rischi dovuti a fattori esterni (es.: evitare di installare il DC in un sito famoso per le alluvioni) o anche, più semplicemente, essere sicuri di installare e mantenere gli impianti (elettrico, idrico, di raffreddamento, antincendio, ecc.) al meglio. In ogni caso, anche per evitare gli errori umani, è sempre bene restringere gli accessi nei datacenter e in quelle aree critiche per il management dell’infrastruttura. Quello che ho detto può sembrare una banalità ma non mi capita tanto di rado di sentire cose del tipo: “l’elettricista ha inavvertitamente tolto corrente ad un rack!”
Inoltre, anche per quanto riguarda la parte più strettamente IT, è sempre una buona norma utilizzare tecnologie consolidate, sufficientemente ridondate e che prevedano strumenti di replicazione o copia dei dati in linea con gli standard (e RPO/RTO) che abbiamo per il nostro DRP.

Un altro importante punto dell’infrastruttura è il sito/i secondario (alcune configurazioni prevedono la suddivisione del rischio su 3 o più data center). Quando si pensa al sito in cui ripristinare l’ambiente operativo è sempre auspicabile cercare una sede con caratteristiche diverse e lontano da quella principale (es.: evitare di mettere il sito di DR sull’altro lato della strada non sarebbe male). Sempre riguardo alle caratteristiche del sito secondario è sempre buona norma avere la sicurezza che questo sia raggiungibile dal network aziendale, con adeguate connessioni telefoniche e con risorse umane in grado di gestire i sistemi in caso di necessità.

Spesso, il sito di DR è dimensionato diversamente da quello principale ed è più piccolo. Il perchè di questa scelta è spesso dovuto alla ricerca di un risparmio sull’infrastruttura ma anche al fatto che, in una eventuale situazione critica, è probabile che l’operatività sia limitata e non servano tutte le risorse computazionali che si usano normalmente.

il costo del DR non è l’infrastruttura

Già, quello che spesso i clienti ignorano o dimenticano è che il costo del DR non è l’infrastruttura ma tutto quello che ci gira intorno!

Il Disaster Recovery Plan è un insieme di documenti e processi che vanno mantenuti efficienti. Per fare tutto ciò sono necessarie risorse umane che aggiornino la documentazione ogni volta che è necessario (upgrade HW, nuovo software, nuovi processi o procedure, ecc.) ed eseguano le adeguate verifiche di ripartenza sui siti di DR secondo procedure standard.

Quando il DR è un fattore importante per valutare la sicurezza di una azienda, i test di verifica vengono seguiti anche da auditor esterni che misurano quanto è dichiarato sul DRP e valutano la correttezza dell’operato degli addetti. Ovviamente ogni azienda può decidere un suo preciso piano di test e la relativa schedulazione, in questo caso  l’importante non è tanto la quantità ma la qualità del test e la capacità di fare le correzioni necessarie in caso si evidenzino dei difetti che possano compromettere il recupero da un disatro.

Gli argomenti del prossimo articolo riguarderanno temi leggermente più tecnici: la prima sincronizzazione dei dati fra i siti, alcune cosniderazioni sul Failback e l’utilizzo delle risorse dell’infrastruttura di DR anche per altre attività