Disaster recovery: cos’è e come si struttura
Quando un data center si ferma, un ransomware cifra i sistemi critici o un errore infrastrutturale interrompe l’accesso alle applicazioni, la domanda non è teorica. Capire disaster recovery cos’è significa stabilire come un’organizzazione ripristina servizi, dati e capacità operative entro tempi accettabili, con criteri misurabili e responsabilità chiare.
Per questo, il disaster recovery non coincide con un semplice backup e non riguarda solo l’IT. È una disciplina di resilienza operativa che traduce il rischio di indisponibilità in architetture, procedure, ruoli, test e metriche di ripristino. Nelle organizzazioni strutturate, la sua qualità si misura quando l’evento si verifica davvero, non quando il piano viene approvato.
Disaster recovery cos’è, in termini operativi
In termini rigorosi, il disaster recovery è l’insieme di strategie, soluzioni tecniche e procedure organizzative finalizzate a ripristinare infrastrutture, applicazioni, dati e servizi ICT dopo un’interruzione grave. L’obiettivo non è tornare online “appena possibile” in modo generico, ma ripristinare ciò che serve, nel tempo definito dal business, con il livello di integrità richiesto.
Questa distinzione è essenziale. Un ambiente può essere tecnicamente riacceso, ma non essere realmente utilizzabile dal punto di vista operativo, regolatorio o contrattuale. Se i dati non sono coerenti, se le dipendenze applicative non sono state considerate, o se il personale non sa eseguire le procedure, il recupero resta incompleto.
Il disaster recovery si colloca normalmente all’interno di un programma più ampio dibusiness continuity. Mentre la business continuity presidia la continuità dei processi critici nel loro complesso, il disaster recovery si concentra sul recupero delle componenti tecnologiche che li sostengono. La relazione tra i due domini è stretta, ma non sovrapponibile.
A cosa serve davvero
La funzione reale del disaster recovery è ridurre l’impatto di un’interruzione severa. Questo impatto può assumere forme diverse: fermo produttivo, perdita di dati, blocco logistico, impossibilità di fatturare, mancato rispetto di SLA, danno reputazionale, esposizione regolatoria o contenzioso contrattuale.
Nelle imprese industriali, per esempio, il tema non riguarda solo server e storage. Un fermo dei sistemi di supervisione, delle piattaforme di pianificazione o delle integrazioni OT-IT può produrre conseguenze immediate sulla continuità operativa del sito. Nei contesti regolamentati, inoltre, la capacità di recupero deve essere coerente con obblighi di controllo, tracciabilità e gestione del rischio.
Per questo il disaster recovery va progettato a partire dagli impatti di business, non dalla sola disponibilità tecnologica. Una replica completa di tutto l’ambiente può sembrare rassicurante, ma spesso è economicamente inefficiente. Al contrario, un perimetro troppo ristretto genera scoperte critiche proprio durante la crisi.
Backup e disaster recovery non sono la stessa cosa
L’equivoco più frequente è considerare il backup come sinonimo di disaster recovery. Il backup è una componente importante, ma da solo non garantisce il ripristino del servizio.
Un backup consente di conservare copie dei dati. Il disaster recovery, invece, definisce anche dove ripristinarli, con quali priorità, in quale sequenza, con quali dipendenze infrastrutturali, sotto quale governo decisionale e con quali tempi obiettivo. Senza questi elementi, il backup resta una misura utile ma insufficiente.
Esiste poi un aspetto spesso sottovalutato: la recuperabilità effettiva. Avere copie disponibili non equivale ad avere dati ripristinabili entro il tempo richiesto. Le organizzazioni mature verificano regolarmente coerenza, integrità, accessibilità e tempi reali di restore, evitando l’errore di assumere che la mera esistenza del dato copiato sia già garanzia di resilienza.
Le metriche che definiscono il piano
Un piano di disaster recovery serio si fonda su parametri chiari. I due più noti sono RTO e RPO.
L’RTO, Recovery Time Objective, indica il tempo massimo entro cui un servizio deve essere ripristinato. L’RPO, Recovery Point Objective, definisce la massima perdita di dati tollerabile misurata nel tempo. Sono metriche semplici solo in apparenza. Se fissate senza analisi di impatto, rischiano di essere irrealistiche o inutili.
Un RTO di pochi minuti, per esempio, richiede investimenti, automazione, architetture ridondate e processi decisionali molto più stringenti rispetto a un obiettivo di alcune ore. Analogamente, un RPO quasi nullo implica tecnologie di replica e controlli operativi che non tutte le applicazioni giustificano. La scelta corretta dipende dalla criticità del processo supportato, dal profilo di rischio e dalla sostenibilità economica delle contromisure.
Accanto a queste metriche, in contesti evoluti si considerano anche priorità di recovery, dipendenze interapplicative, requisiti minimi di esercizio e criteri di accettazione del ripristino.
Come si struttura un programma di disaster recovery
La progettazione parte da una business impact analysis e da unavalutazione del rischio. Senza questa base, il piano tende a riflettere l’architettura IT esistente, non le esigenze operative dell’organizzazione. L’ordine corretto è opposto: prima si definiscono processi critici, impatti, tolleranze e scenari; poi si dimensionano soluzioni e procedure.
Analisi degli scenari
Non tutti i disastri hanno la stessa natura. Un attacco ransomware, un guasto elettrico prolungato, un errore umano su sistemi core, un incendio in sala server o l’indisponibilità di un provider cloud richiedono ipotesi di recovery diverse. La qualità del piano dipende dalla capacità di modellare scenari credibili, non cataloghi astratti di minacce.
Definizione del perimetro critico
A questo punto si identificano asset, applicazioni, dati, interfacce e fornitori che sostengono i processi prioritari. È qui che emergono le dipendenze spesso invisibili: autenticazione, DNS, connettività, piattaforme middleware, strumenti di monitoraggio, repository di configurazione. Trascurarle compromette il ripristino anche quando i sistemi principali risultano disponibili.
Strategia tecnica di recupero
La strategia può prevedere sito secondario, replica geografica, cloud recovery, infrastrutture ad alta disponibilità, restore da backup o combinazioni ibride. Non esiste una soluzione universalmente migliore. In alcuni casi prevale l’esigenza di velocità; in altri, quella di contenimento dei costi o di segregazione del rischio cyber.
Un’organizzazione manifatturiera con impianti distribuiti avrà esigenze diverse rispetto a una realtà fortemente digitalizzata con servizi h24. La scelta va quindi governata con logica di rischio e di impatto, non per imitazione di modelli altrui.
Procedure, ruoli e governance
La tecnologia, da sola, non esegue il piano. Servono runbook, criteri di escalation, autorizzazioni, ruoli di crisi, contatti aggiornati e una chiara catena decisionale. Durante un’interruzione severa, l’ambiguità organizzativa produce ritardi tanto quanto il guasto tecnico.
Per questo le organizzazioni più mature distinguono tra governance del piano, gestione dell’incidente, esecuzione tecnica del recovery e comunicazione verso stakeholder interni ed esterni. Sono funzioni diverse, con competenze e responsabilità differenti.
Il punto critico: i test
Un piano di disaster recovery non testato è, nella migliore delle ipotesi, un’ipotesi. Il test verifica se obiettivi, procedure, configurazioni e persone sono davvero allineati.
Non tutti i test devono essere full interruption test. Esistono esercitazioni documentali, walkthrough tecnici, simulazioni di scenario, test di failover parziale e prove complete di ripristino. La scelta dipende dal livello di maturità, dalla criticità dei servizi e dal rischio operativo associato alla prova stessa.
Il punto non è “fare un test all’anno” per conformità formale. Il punto è usare il test come strumento di validazione e miglioramento. Ogni esercitazione dovrebbe produrre evidenze, scostamenti rispetto agli RTO e RPO, azioni correttive, aggiornamento della documentazione e revisione delle dipendenze.
Standard, audit e aspettative del mercato
Nel mercato corporate e assicurativo, il disaster recovery è sempre meno un tema dichiarativo e sempre più un ambito verificabile. Clienti, assicuratori, auditor e funzioni di controllo chiedono evidenze: analisi di impatto, criteri di classificazione, test eseguiti, risultati, remediation plan, copertura dei fornitori critici.
Questo cambia anche il ruolo della formazione. Non basta conoscere la terminologia. Serve capacità di progettare programmi coerenti con standard riconosciuti,requisiti di governancee scenari operativi reali. In questo senso, un approccio metodologico rigoroso consente di trasformare il disaster recovery da documento tecnico a capacità organizzativa misurabile, come avviene nei percorsi specialistici più evoluti proposti da operatori come Continuitaly.
Gli errori più comuni
L’errore più diffuso è pensare al disaster recovery come progetto una tantum. In realtà è un processo vivo, che cambia con l’architettura, con i fornitori, con i processi e con il profilo di minaccia.
Un secondo errore è trattarlo come materia esclusiva dell’IT. Se gli obiettivi non derivano dal business, il rischio è investire troppo su servizi marginali e troppo poco su quelli realmente critici.
Il terzo errore riguarda i test di facciata. Se si provano solo componenti isolate, senza verificare dipendenze, tempi reali e decisioni organizzative, il livello di fiducia prodotto è fuorviante.
C’è infine un tema di supply chain. Sempre più servizi essenziali dipendono da provider esterni, piattaforme cloud, software house e partner di connettività. Un disaster recovery credibile deve estendere il proprio perimetro di valutazione anche a queste dipendenze contrattuali e operative.
Un buon programma di disaster recovery non promette invulnerabilità. Definisce, con disciplina e realismo, quanto fermo è tollerabile, quanta perdita di dati è accettabile e quali capacità devono essere dimostrate prima che l’evento si manifesti. È qui che la resilienza smette di essere un principio generale e diventa una competenza che regge sotto pressione.
This post is also available in:
