Disaster Recovery

Cos'è

Il disaster recovery (DR) è l'insieme di processi, tecnologie e piani scritti che permettono di ripristinare sistemi IT e dati dopo un evento distruttivo: un guasto hardware grave, un incendio o un allagamento nel data center, un attacco informatico che compromette l'infrastruttura primaria, o anche solo un errore umano catastrofico su un sistema centrale. Un piano di DR serio non è un documento generico: definisce, per ogni sistema critico, dove si trova esattamente la copia di ripristino, chi è responsabile di attivarla, in che ordine i sistemi vanno ripristinati (perché ripristinare tutto insieme e a caso non funziona quasi mai, alcuni sistemi dipendono da altri), e con quali obiettivi misurabili: il tempo massimo di fermo tollerabile (RTO, Recovery Time Objective) e la quantità massima di dati che ci si può permettere di perdere (RPO, Recovery Point Objective). Senza questi due numeri concordati in anticipo con il business, ogni piano di DR resta un esercizio teorico.

Perché conta

La differenza tra avere un backup e avere un vero piano di disaster recovery è la stessa che passa tra avere degli estintori in magazzino e avere un piano antincendio scritto e provato: nel momento dell'emergenza, quello che conta è sapere esattamente cosa fare, in che ordine, senza doverlo inventare sotto pressione con mezza azienda ferma e il telefono che squilla. Anche il NIST, nella sua guida alla contingency planning, insiste proprio su questo: un piano scritto ma mai esercitato vale ben poco quando arriva l'evento reale. Le aziende con cui lavoro che hanno davvero testato il proprio piano di DR, non solo scritto e archiviato in un cassetto digitale, sono sistematicamente quelle che tornano operative in ore, non in giorni. La differenza tra i due scenari, in termini di fatturato perso e reputazione, è enorme — ed è quasi sempre una questione di preparazione, non di sfortuna.

Da dove parto quando costruisco un piano di DR

Quando aiuto un'azienda a costruire il suo primo piano di DR, non parto dalla tecnologia ma da una mappa: quali sistemi, se si fermano, bloccano davvero il lavoro entro ore, e quali invece possono aspettare giorni senza conseguenze gravi. Sembra ovvio ma quasi nessuno lo ha scritto da qualche parte prima che io lo chieda. Da lì si definiscono RTO e RPO realistici per ogni sistema — non aspirazionali, realistici, perché un RTO di 15 minuti su un sistema che oggi richiederebbe ore per essere ripristinato è solo un numero sulla carta che crea false aspettative nel management. Il primo test, per me, è sempre a bassa visibilità: coinvolgo un solo sistema non critico, cronometro tutto, e uso quello che emerge per correggere il piano prima di estenderlo a sistemi più delicati. È un investimento di tempo che si ripaga alla prima vera emergenza, quando le decisioni vanno prese in minuti, non in ore di riunione.

// Nota pratica

Un piano di DR scritto e mai testato è quasi peggio di non averlo: dà un falso senso di sicurezza. Il test dovrebbe includere uno scenario realistico (non 'ripristina un file', ma 'il server principale non risponde più, parti da zero') con tempi cronometrati.