Il disaster recovery nella vita quotidiana: pratiche che evitano la crisi

La maggior parte delle organizzazioni colpite da un disastro disponevano di un piano di ripristino su carta. Il problema è che il piano era sulla carta, e solo lì. Documentato da qualche parte, omologato una volta, mai esercitato. Quando è arrivato l'incidente, hanno scoperto che un piano che non vive nella routine è utile quanto un estintore sigillato e scaduto.

Il disaster recovery non è un progetto che può essere consegnato e archiviato. È una disciplina operativa, fatta di piccole abitudini ripetute. La differenza tra un'organizzazione che si riprende in poche ore e una che impiega settimane raramente sta nella sofisticatezza del piano. Dipende da quanto è stato praticato prima che fosse necessario.

Questo articolo è per coloro che già comprendono l'importanza del disaster recovery e vogliono sapere come tradurlo in pratiche quotidiane, per i team tecnologici, operativi e di sicurezza che devono mantenere il piano in vita, non accantonarlo.

Il cambio di mentalità: da evento a routine

L’errore di base è pensare al disaster recovery come una risposta a un evento futuro. La mentalità giusta è l’opposto: la ripresa si costruisce ogni giorno, nelle piccole scelte di come si opera.

Ogni backup effettuato e verificato oggi sarà un giorno in meno di dati persi domani. Ogni prova di restauro eseguita è una sorpresa in meno il giorno dell'incidente. Ogni automazione del provisioning equivale a un'ora in meno di inattività.

Quando il recupero diventa parte del normale flusso di lavoro, smette di essere un piano eroico per una brutta giornata e diventa una proprietà del sistema. L’obiettivo non è avere un piano imponente, ma rendere il disastro un evento noioso, previsto e provato.

Backup: la pratica quotidiana più trascurata

Il backup è il pane quotidiano del ripristino e, proprio perché è basilare, di solito viene eseguito in modo inadeguato. La regola più conosciuta e più ignorata è la regola 3-2-1: tre copie dei dati, su due diversi tipi di supporto, di cui almeno una al di fuori della posizione primaria.

Nella vita di tutti i giorni ciò significa abitudini concrete. Automatizza i backup, in modo che non dipendano dalla memorizzazione di qualcuno. Monitora se stanno effettivamente accadendo, perché i backup che falliscono silenziosamente sono la categoria peggiore. E, soprattutto, isolare almeno una copia dell'ambiente di produzione.

Questo isolamento è diventato urgente con il ransomware. Gli aggressori moderni cercano e distruggono i backup connessi prima di crittografare la produzione. Una copia immutabile o disconnessa, che non può essere modificata o eliminata nemmeno da un amministratore compromesso, è diventata l'ultima linea di difesa. Giorno per giorno, garantire che questa copia esista e sia veramente isolata è uno dei compiti più importanti dell’operazione.

La pratica che più manca: testare il restauro

Ecco la scomoda verità: i backup che non sono mai stati ripristinati non contano. Non hai un backup, hai una copia di validità sconosciuta.

La pratica che separa i team maturi è il test di ripristino periodico. A intervalli regolari, ripristina i dati realmente, in un ambiente di test, e verifica se l'operazione ritorna. È in questo esercizio che emergono i veri problemi: il backup era incompleto, la documentazione non era aggiornata, il ripristino richiede otto ore quando l'azienda ne tollera solo due, nessuno ricordava la password del sistema di ripristino.

Scoprirlo in un test programmato è un'esperienza di apprendimento. Scoprirlo il giorno del disastro è una catastrofe. La sola differenza di costo tra i due scenari giustifica la disciplina dei test.

Una buona pratica è trattare questi test come i vigili del fuoco trattano le simulazioni: contrassegnati, effettivamente eseguiti, con errori documentati e corretti. Non è sufficiente eseguire il ripristino una volta e il gioco è fatto, l'ambiente cambia e il test deve tenere il passo.

Automazione: trasforma il recupero in comando

Più il recupero dipende da passaggi manuali, più è fragile. Le persone sotto stress dimenticano passi, commettono errori, perdono tempo a cercare informazioni. La pratica che riduce questo rischio è l’automazione.

Infrastructure as Code è il fulcro. Quando l'intero ambiente, server, reti, configurazioni, è descritto in file con versione, ricrearlo dopo un disastro smette di essere un lavoro artigianale di una giornata e diventa l'esecuzione di un processo. Non lo ricostruisci nella memoria; riapplica una definizione testata.

Giorno per giorno, ciò significa evitare modifiche manuali che non siano presenti nel codice, mantenere queste definizioni aggiornate e controllare la versione e testare regolarmente se l'infrastruttura effettivamente si ricrea da esse. Un ambiente che esiste solo perché qualcuno lo ha creato anni fa è un disastro pronto ad accadere.

Documentazione chiara e ruoli chiari

Al momento dell'incidente, nessuno ha il tempo di capire chi fa cosa. La pratica quotidiana consiste nel mantenere la documentazione di ripristino breve, chiara, aggiornata e, soprattutto, accessibile anche se i sistemi interni non sono attivi. Un piano memorizzato nel sistema che si è bloccato è inutile.

Anche definire in anticipo i ruoli è un lavoro di routine: chi dichiara l’incidente, chi esegue il ripristino, chi comunica internamente ed esternamente, chi decide quando tornare online. E prova questa coreografia, in modo che nel giorno reale sia memoria muscolare, non improvvisazione.

Una tecnica efficace presa in prestito dalla risposta agli incidenti è la revisione post-evento. Ogni volta che qualcosa va storto, anche se si tratta di un disastro, registra cosa è successo e cosa può essere migliorato, senza caccia alle streghe. Ogni incidente diventa carburante per rafforzare la routine.

Riflessione critica: il nemico è l'autocompiacimento

La minaccia più grande al ripristino di emergenza non è tecnica, ma culturale. È il compiacimento che cresce proprio quando tutto va bene. Mesi senza incidenti creano la sensazione che il piano non sia più necessario, i test vengono rinviati, i backup non vengono più verificati. Fino al giorno in cui arriva il conto.

Una riflessione onesta per chi opera: il disaster recovery compete per l'attenzione con tutto ciò che è urgente e visibile, e quasi sempre perde, perché il suo valore è invisibile finché non arriva il disastro. Spetta alla leadership tecnica proteggere questo tempo, trattare i test come non negoziabili e resistere alla tentazione di declassare ciò che non produce risultati immediati.

Alla fine, il ripristino di emergenza eseguito correttamente è silenzioso. Quando arriva l'incidente e l'operazione riprende nel giro di pochi minuti, nessuno applaude, perché sembra che non sia successo niente. Questo silenzio è un successo. Si basa ogni giorno su backup verificati, ripristini testati e processi collaudati, molto prima di qualsiasi crisi.

Se il tuo team dispone di backup ma non ha mai testato un ripristino completo, questo è il punto di partenza più prezioso. Esistono altri articoli di blog su continuità, sicurezza e DevOps che completano queste pratiche. Se vuoi strutturare questa routine nella tua operazione, vale la pena parlarne.