Disaster recovery: cos’è, come funziona e come si pianifica

Disaster recovery in sintesi

• Obiettivo: ridurre al minimo tempo di inattività e perdita di dati dopo un’interruzione grave, misurando le due soglie RTO e RPO.
• Differenza dal backup: il backup copia i dati, il disaster recovery ripristina l’intera infrastruttura operativa, applicazioni comprese.
• Documento di riferimento: il DRP formalizza ruoli, procedure e tempi, ed è parte del più ampio piano di continuità operativa.
• Fasi principali: analisi d’impatto, classificazione dei sistemi, scelta del sito di ripristino, test periodici.
• Modalità di erogazione: infrastruttura dedicata, sito secondario proprio oppure servizio in cloud (DRaaS).
• Quando si attiva: a fronte di eventi naturali, incidenti causati dall’uomo o guasti tecnologici che bloccano i sistemi critici.

Cosa prevede il disaster recovery

Il disaster recovery prevede un insieme coordinato di misure tecniche e organizzative pensate per riportare in funzione sistemi, applicazioni e dati entro tempi definiti in anticipo. Non si tratta di un singolo strumento, ma di una combinazione di infrastrutture ridondanti, procedure documentate e ruoli assegnati che entrano in azione quando un evento interrompe l’erogazione dei servizi.

Rientrano in questo ambito la replica dei dati su siti secondari, i meccanismi di failover e failback, la definizione delle priorità di ripristino tra applicazioni critiche e secondarie, e la verifica periodica che le procedure funzionino davvero. L’obiettivo primario non è eliminare il rischio di un’interruzione, impossibile da azzerare, ma contenerne la durata e l’impatto sui processi aziendali.

Per questo ogni disaster recovery si fonda su due soglie concordate a monte: il tempo massimo di fermo tollerabile e la quantità massima di dati che l’organizzazione può permettersi di perdere. Queste soglie, descritte nel dettaglio più avanti, guidano ogni scelta tecnica successiva, dalla frequenza di replica dei dati al tipo di sito di emergenza da attivare.

Le procedure di disaster recovery si applicano sia a eventi di origine naturale, come alluvioni o terremoti, sia a incidenti provocati dall’uomo, come attacchi ransomware o errori di configurazione, sia a guasti puramente tecnologici, come un’interruzione di corrente prolungata o il fallimento di un componente hardware critico.

Perché serve un piano di disaster recovery

Un piano di disaster recovery serve perché l’assenza di una procedura strutturata trasforma un incidente tecnico in una crisi operativa prolungata, con conseguenze economiche che aumentano rapidamente con il passare delle ore. Il costo medio globale di una violazione dei dati ha raggiunto circa 4,44 milioni di dollari, con una riduzione di quasi il 9% rispetto al picco precedente grazie a tempi di rilevazione e risposta più rapidi, come riporta Statistiche sulle violazioni dei dati per il 2026 (2026).

Gran parte delle emergenze che un piano di disaster recovery è chiamato a gestire ha origine da minacce informatiche: circa il 44% delle violazioni coinvolge ransomware, spesso innescato da VPN esposte o dispositivi periferici non aggiornati, mentre gli errori umani sono stimati come causa di circa il 60% di tutti gli incidenti di sicurezza, secondo la stessa fonte. Un piano documentato riduce l’impatto di questi fattori perché definisce in anticipo chi fa cosa, quali sistemi ripristinare per primi e con quali strumenti.

Oltre alla componente economica, un piano di disaster recovery incide sulla conformità normativa dei settori regolamentati e sulla continuità dei rapporti con clienti e fornitori. Le organizzazioni che non dispongono di procedure testate rischiano tempi di ripristino non pianificati, con un effetto a catena su reputazione, obblighi contrattuali e, in alcuni settori, responsabilità legali.

Le vulnerabilità software e hardware non corrette, come quelle che favoriscono un attacco di cross-site scripting, sono coinvolte in circa il 20% delle violazioni, con un aumento di circa un terzo rispetto all’anno precedente: un dato che spiega perché il disaster recovery non possa prescindere da un monitoraggio costante dell’infrastruttura esposta.

Differenza tra backup e disaster recovery

Il backup è la copia dei dati salvata periodicamente per proteggerli da cancellazioni accidentali, guasti o attacchi; il disaster recovery è il processo più ampio che ripristina l’intera infrastruttura operativa, comprese applicazioni, configurazioni e connettività, non solo i file. In pratica un backup risponde alla domanda “come recupero questo documento”, mentre un piano di disaster recovery risponde alla domanda “come torno operativo entro le prossime ore”.

Un backup senza un piano di disaster recovery lascia comunque l’organizzazione priva di server, rete e applicazioni funzionanti: i dati sono salvi, ma l’operatività resta ferma fino a quando l’infrastruttura non viene ricostruita manualmente. Per questo le due componenti si integrano: il backup alimenta i dati che il disaster recovery utilizza per ripristinare rapidamente l’ambiente completo tramite replica su un sito secondario.

Chi distingue backup e ripristino intende, con il secondo termine, l’atto tecnico di riportare i dati da una copia salvata alla loro posizione originale: un’operazione contenuta nel backup, non equivalente al disaster recovery, che agisce su un perimetro molto più ampio e coinvolge reindirizzamento del traffico, riattivazione di servizi core e verifica dell’integrità dell’intero ambiente.

Che differenza c’è tra RTO e RPO

L’RTO indica il tempo massimo tollerabile di inattività prima che l’interruzione causi danni gravi all’organizzazione, mentre l’RPO indica la quantità massima di dati, misurata in tempo trascorso dall’ultimo backup o replica utile, che l’organizzazione può permettersi di perdere. Il primo misura la velocità del ripristino, il secondo la profondità accettabile della perdita di dati.

RTO

Tempo massimo entro cui un sistema deve tornare operativo dopo un’interruzione; determina la scelta dell’infrastruttura di ripristino (sito caldo, tiepido o freddo).

RPO

Intervallo massimo di dati perdibili, calcolato tra l’ultimo salvataggio valido e il momento dell’incidente; determina la frequenza di replica o backup necessaria.

Entrambe le metriche vengono definite durante la BIA, l’analisi che misura il costo di un’interruzione per ciascun processo aziendale. Un sistema con RTO molto basso richiede infrastrutture ridondanti sempre attive e quindi investimenti maggiori; un RPO molto basso richiede una replica dei dati quasi continua, con soluzioni di replica sincrona anziché asincrona.

Le due soglie non vanno confuse: un’organizzazione può tollerare un RTO di alcune ore ma richiedere un RPO di pochi minuti, se la perdita di transazioni recenti ha un impatto economico maggiore della momentanea indisponibilità del sistema. La combinazione delle due soglie, non il valore isolato di una sola, definisce la strategia di disaster recovery più adatta a ciascun sistema.

Continuità operativa e disaster recovery: cosa cambia

La continuità operativa, o BCP, è il piano complessivo che garantisce la prosecuzione di tutte le attività aziendali durante un’emergenza, comprese quelle non informatiche come la logistica, il personale e le comunicazioni esterne. Il disaster recovery, formalizzato nel DRP, ne è un sottoinsieme specifico, focalizzato sul ripristino di sistemi IT, dati e infrastrutture tecnologiche.

In altre parole, la continuità operativa risponde alla domanda “come continua a funzionare l’azienda durante l’emergenza”, mentre il disaster recovery risponde alla domanda più circoscritta “come tornano disponibili i sistemi informatici”. Un’organizzazione può avere processi manuali di continuità anche senza sistemi IT attivi, ma non può considerarsi davvero resiliente se il disaster recovery non è integrato nel piano più ampio.

Le soluzioni concrete per la continuità operativa includono l’identificazione di processi alternativi manuali per le funzioni classificate come delicate, l’attivazione di sedi di lavoro alternative, procedure di comunicazione di crisi e, sul fronte tecnologico, le stesse strategie di disaster recovery descritte più avanti: siti di replica, infrastrutture ridondanti e servizi di ripristino in cloud.

La classificazione dei sistemi, descritta nella sezione dedicata alla costruzione del piano, è il punto di contatto diretto tra i due documenti: stabilisce quali funzioni richiedono un ripristino informatico immediato e quali possono invece essere gestite temporaneamente con procedure manuali previste dal piano di continuità operativa.

Come si costruisce un piano di disaster recovery

Un piano di disaster recovery si costruisce in quattro fasi sequenziali, ciascuna propedeutica alla successiva: analisi dell’impatto, classificazione dei sistemi, scelta della strategia di replica, test periodici.

1. Business Impact Analysis: si valutano i rischi e si misura il costo di un’interruzione per ciascun processo, definendo RTO e RPO specifici per ogni sistema.
2. Classificazione dei sistemi: ogni applicazione viene assegnata a una categoria di criticità, che determina la priorità di ripristino.
3. Pianificazione e replica: si sceglie tra backup in cloud, sito secondario proprio o replica sincrona o asincrona dei dati, in base a RTO e RPO stabiliti.
4. Test e simulazioni: il piano viene verificato periodicamente per controllare che i tempi effettivi di ripristino corrispondano agli obiettivi dichiarati.

La classificazione dei sistemi, in particolare, distingue quattro livelli di criticità che condizionano ogni scelta successiva, dalla priorità tecnica al budget assegnato.

La fase di test è spesso quella più trascurata, eppure è l’unica che verifica se RTO e RPO stabiliti sulla carta corrispondono ai tempi reali di ripristino. Un piano mai testato resta una dichiarazione d’intenti, non una garanzia operativa.

Tipologie e strategie di disaster recovery

Le soluzioni per la continuità operativa sul fronte tecnologico si articolano principalmente in tre modelli di sito di emergenza, distinti per livello di prontezza e costo: hot site, warm site e cold site. A questi si affianca il modello in cloud, il DRaaS, che elimina la necessità di mantenere un’infrastruttura secondaria fisica.

Se il sistema è classificato come critico: scegli un hot site

Per i sistemi critici, con tolleranza all’interruzione quasi nulla, la scelta ricade su un hot site, un ambiente già attivo e sincronizzato con quello primario, capace di assorbire il carico in pochi minuti tramite failover automatico.

Se il sistema è vitale o delicato: valuta un warm o cold site

Per i sistemi vitali o delicati, in cui alcuni giorni di tolleranza sono accettabili, un warm site (parzialmente attivo) o un cold site (infrastruttura predisposta ma da avviare) riducono i costi fissi senza compromettere il ripristino nei tempi concordati.

Se la perdita di dati deve essere quasi nulla: usa la replica sincrona

Quando l’RPO richiesto è vicino allo zero, la replica sincrona scrive i dati contemporaneamente su sito primario e secondario; quando è accettabile un ritardo di minuti o ore, la replica asincrona riduce il carico sulla rete e i costi infrastrutturali.

Non esiste una distanza fissa valida per ogni organizzazione tra sito primario e sito di disaster recovery: la distanza minima adeguata dipende dal tipo di rischio da coprire. Per guasti tecnici locali, come un’interruzione elettrica o un guasto hardware, può bastare un’area diversa dello stesso edificio o una sede vicina; per rischi di origine naturale su scala regionale, come un terremoto o un’alluvione, la distanza deve essere sufficiente a escludere che lo stesso evento colpisca entrambi i siti contemporaneamente. La valutazione corretta richiede un’analisi geografica dei rischi specifici dell’area, non un valore standard applicabile a ogni caso.

Le strategie in cloud, erogate come DRaaS, stanno progressivamente sostituendo i siti secondari fisici dedicati, perché permettono di attivare capacità di calcolo solo al momento del disastro, riducendo i costi fissi di mantenimento di un’infrastruttura inutilizzata nella quotidianità.

Errori frequenti nella gestione del disaster recovery

L’errore più comune consiste nel considerare il backup come equivalente a un piano di disaster recovery: avere copie dei dati non garantisce che server, rete e applicazioni tornino operativi in tempi rapidi, perché manca la componente di ripristino dell’infrastruttura completa.

Un secondo errore riguarda la mancata manutenzione del piano: un DRP scritto una sola volta e mai aggiornato perde validità man mano che cambiano applicazioni, fornitori e configurazioni di rete. Le procedure automatizzate, come quelle gestite tramite cron job per l’avvio pianificato di repliche e verifiche, richiedono controlli periodici per restare allineate ai sistemi effettivamente in produzione.

Un terzo errore è sottovalutare le minacce causate da attacchi mirati come un attacco DDoS o un tentativo di accesso tramite attacco brute force: a differenza di un guasto hardware, questi eventi possono colpire contemporaneamente sito primario e backup se non sono adeguatamente isolati, vanificando la strategia di ripristino.

Infine, molte organizzazioni non testano mai il piano in condizioni realistiche, limitandosi a verifiche documentali. Solo una simulazione completa, che coinvolge failover effettivo e misurazione dei tempi reali, dimostra se RTO e RPO dichiarati sono raggiungibili nella pratica.

Domande frequenti sul disaster recovery

Qual è l’obiettivo principale del piano di disaster recovery?

L’obiettivo principale è riportare operativi sistemi e dati entro un tempo definito in anticipo, minimizzando sia la durata dell’interruzione sia la quantità di informazioni perdute, secondo le soglie RTO e RPO stabilite per ciascun sistema durante l’analisi d’impatto.

Cosa significa “recovery plan”?

Con “recovery plan” si indica, in modo generico, il documento operativo che descrive le azioni da compiere per ripristinare un sistema dopo un’interruzione; nell’ambito aziendale coincide con il disaster recovery plan, il manuale che formalizza ruoli, procedure e tempi del ripristino.

Cosa si intende per recovery?

Il termine inglese recovery si traduce con “ripristino” o “recupero” e indica, nel contesto informatico, il processo tecnico con cui un sistema, un dato o un’applicazione tornano allo stato funzionante precedente a un guasto o a un’interruzione.

Cos’è la strategia di backup 3-2-1-1-0?

È un’evoluzione della regola di backup 3-2-1 pensata per rafforzare la resilienza contro gli attacchi ransomware: prevede più copie dei dati su supporti diversi, con almeno una copia offline o immutabile e verifiche periodiche che garantiscano zero errori di ripristino. Riguarda la strategia di backup, non sostituisce un piano di disaster recovery completo.

Cosa succede se non si fa il backup dei dati?

In assenza di backup, la perdita di un file, un database o un intero sistema diventa definitiva in caso di guasto, cancellazione accidentale o attacco informatico, perché non esiste una copia da cui recuperare i dati: un rischio che nessuna strategia di disaster recovery può compensare se manca la base dati da ripristinare.

Backup di Google, Android o WhatsApp: riguardano il disaster recovery?

No: le funzioni di backup di sistemi operativi mobili o di singole applicazioni riguardano la protezione dei dati personali su un dispositivo, non il ripristino di infrastrutture aziendali. Condividono con il disaster recovery solo il principio di fondo, cioè conservare una copia utilizzabile in caso di perdita, ma non ne costituiscono una componente.

Come si fa a ripristinare il backup?

Il ripristino di un backup consiste nel recuperare i dati salvati in precedenza e riportarli nella posizione originale o in un nuovo ambiente; la procedura esatta dipende dallo strumento utilizzato per il salvataggio e dal tipo di dato da recuperare, file singolo o intero sistema.