Cos'è un piano di disaster recovery? Componenti, RTO/RPO, strategie e checklist

Un piano di disaster recovery (DR) è una procedura scritta e testata per ripristinare sistemi IT e dati dopo una grave interruzione, un attacco informatico o la perdita di una sede. Indica chi dichiara il disastro, quali sistemi ripartono per primi, con quale rapidità (RTO), quanta perdita di dati è accettabile (RPO) e i passaggi per il failover e il ritorno alla situazione normale.

Punti chiave

• Un piano di DR ripristina la tecnologia; un piano di business continuity mantiene in funzione l'intera azienda. Servono entrambi, e il piano di DR dovrebbe essere un sottoinsieme del piano di continuità.
• Ogni decisione di ripristino parte da due numeri per sistema: il recovery time objective (RTO) e il recovery point objective (RPO).
• Il DR nel cloud segue quattro strategie standard: backup e ripristino, pilot light, warm standby e multi-site active/active. Costo e velocità di ripristino crescono insieme.
• Un piano non testato è un'ipotesi. Testate almeno una volta all'anno, e più spesso i sistemi critici, con esercitazioni che vanno dal tabletop al failover completo.
• Nell'UE, l'articolo 21 della NIS2 elenca "la gestione dei backup e il disaster recovery" tra le misure di sicurezza minime. In Svezia si applica tramite la legge sulla cybersicurezza (Cybersäkerhetslagen) dal 15 gennaio 2026.

Cos'è un piano di disaster recovery?

È il manuale tecnico per riportare in funzione i sistemi dopo un evento che la normale resilienza non riesce ad assorbire. I fattori scatenanti tipici sono ransomware, il guasto di un data center o di una region cloud, un database corrotto, una modifica fallita, un incendio o un'alluvione.

NIST SP 800-34 definisce il piano di DR come "un piano scritto per ripristinare uno o più sistemi informativi in una struttura alternativa in risposta a un grave guasto hardware o software o alla distruzione delle strutture" (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). La stessa guida sottolinea che il piano di DR è incentrato sui sistemi informativi, mentre il piano di business continuity copre i processi aziendali come le paghe o il servizio clienti.

Troverete anche i termini "IT disaster recovery plan" e "DRP". Significano la stessa cosa. Un buon piano è abbastanza breve da poter essere usato sotto pressione: poteri decisionali, priorità, runbook, contatti ed evidenza dei test. Un lungo documento di policy che nessuno apre dall'ultimo audit non conta.

Disaster recovery e business continuity

Il disaster recovery ripristina l'IT. La business continuity fa sì che l'organizzazione continui a erogare prodotti e servizi mentre IT, persone, sedi o fornitori sono compromessi. Il whitepaper AWS sul DR lo dice chiaramente: il piano di DR "dovrebbe essere un sottoinsieme del piano di business continuity (BCP) dell'organizzazione, non un documento a sé stante."

Per un confronto più approfondito, compreso il BCDR in AWS, Azure e Google Cloud, leggete la nostra guida a disaster recovery e business continuity nel cloud.

Backup e disaster recovery

Il backup è una copia dei dati. Il disaster recovery è la capacità di far funzionare di nuovo il servizio. Potete avere backup perfetti ed essere comunque fermi per giorni se nessuno ha scritto come ricostruire intorno ad essi server, reti, identità e DNS. I backup sono uno degli input del piano di DR; la regola 3-2-1 (tre copie, due tipi di supporto, una fuori sede) è una base sensata.

Qual è lo scopo di un piano di DR?

Lo scopo è rendere il ripristino prevedibile. Quando arriva un disastro, il piano sostituisce l'improvvisazione con decisioni prese con calma in anticipo.

• Limitare il downtime. I sistemi critici tornano entro un tempo concordato, in un ordine concordato.
• Limitare la perdita di dati. Backup e replica girano con la frequenza approvata dal business.
• Eliminare le ambiguità. Tutti sanno chi può dichiarare un disastro, chi guida e chi parla con clienti e autorità.
• Controllare i costi. Non tutti i sistemi richiedono un hot standby. Il piano registra quali sì e perché.
• Dimostrare la conformità. Autorità di controllo, auditor, assicuratori e grandi clienti chiedono sempre più spesso una capacità di ripristino testata, non solo una policy.

Sono anche i vantaggi di cui chiedono gli acquirenti. Un piano che è stato messo alla prova accorcia le interruzioni reali perché le persone hanno già provato i passaggi.

RTO e RPO: i due numeri che guidano il piano

Il recovery time objective (RTO) è per quanto tempo un sistema può restare fermo. Il recovery point objective (RPO) è quanta quantità di dati, misurata in tempo, potete permetterti di perdere. AWS definisce l'RTO come "il ritardo massimo accettabile tra l'interruzione del servizio e il suo ripristino" e l'RPO come "il tempo massimo accettabile trascorso dall'ultimo punto di recupero dei dati."

Esempio pratico. Un negozio online concorda per il sistema ordini un RTO di 4 ore e un RPO di 15 minuti. Se il database si guasta alle 10:00, gli ordini devono essere di nuovo accettati entro le 14:00 al più tardi, e al massimo gli ordini effettuati tra le 09:45 e le 10:00 potrebbero dover essere reinseriti o recuperati in altro modo. Un backup notturno non può rispettare questo RPO; il negozio ha bisogno di log shipping o replica almeno ogni 15 minuti. La sua wiki interna, al contrario, potrebbe accettare un RTO di 3 giorni e un RPO di 24 ore, che un backup giornaliero soddisfa.

Due regole pratiche aiutano:

• Fissate gli obiettivi per sistema, tramite una business impact analysis, non un unico numero per "l'IT". L'impatto può anche cambiare nel tempo: AWS osserva che un'interruzione del sistema paghe poco prima del giorno di pagamento fa molto più danno di una subito dopo.
• Mantenete l'RTO sotto il massimo downtime tollerabile del processo aziendale. NIST SP 800-34 spiega che l'RTO "deve normalmente essere più breve" di quel limite, perché i dati devono comunque essere rielaborati dopo il ritorno dei sistemi.

Per altri esempi e un metodo passo passo per fissare entrambi gli obiettivi, leggete RPO e RTO nel disaster recovery spiegati.

Strategie di DR: dal backup e ripristino all'active/active

Il whitepaper AWS Disaster Recovery of Workloads on AWS raggruppa il DR nel cloud in quattro strategie. Gli stessi schemi valgono su Azure (dove Azure Site Recovery replica le macchine virtuali in una region secondaria) e su Google Cloud.

La distinzione tra pilot light e warm standby confonde molti team. AWS la mette così: un ambiente pilot light "non può elaborare richieste senza che prima venga intrapresa un'ulteriore azione", mentre un warm standby "può gestire il traffico (a capacità ridotta) immediatamente." Il nostro articolo sul disaster recovery pilot light tratta questo schema nel dettaglio.

Due punti del whitepaper sono spesso trascurati. Primo, un'architettura multi-AZ all'interno di una region "può già soddisfare gran parte delle vostre esigenze di mitigazione del rischio" per i guasti a livello di data center; una seconda region serve per eventi che coinvolgono un'intera region o per requisiti normativi. Secondo, backup e ripristino è rapido solo se l'infrastruttura è definita come codice, perché dovete ridistribuire reti, server e configurazione oltre ai dati.

DRaaS e disaster recovery nel cloud

Il disaster recovery as a service (DRaaS) significa che un fornitore replica i vostri server nel suo cloud e gestisce gli strumenti di failover. AWS Elastic Disaster Recovery e Azure Site Recovery sono le opzioni native; i managed service provider costruiscono intorno ad esse runbook, monitoraggio e test. Il DRaaS trasforma un progetto in conto capitale (un secondo data center) in un costo di esercizio, ma non toglie la vostra responsabilità di fissare RTO/RPO, approvare il piano e partecipare ai test.

Siti hot, warm e cold

Prima delle region cloud, le strategie di DR si descrivevano in base alla prontezza del sito alternativo. NIST SP 800-34 descrive i cold site come spazi con alimentazione, raffreddamento e connettività ma senza attrezzature, i warm site come parzialmente attrezzati con hardware e telecomunicazioni, e gli hot site come completamente configurati con hardware, infrastruttura e personale. Un cold site è il più economico ma può richiedere giorni o settimane per essere attivato. Gli equivalenti cloud corrispondono approssimativamente a backup e ripristino (cold), pilot light o warm standby (warm) e active/active (hot). Approfondite in cos'è un hot site nel disaster recovery.

Cosa deve includere un piano di DR? Checklist

Usate questa checklist per costruire un nuovo piano o verificarne uno esistente. Ogni riga dovrebbe esistere come artefatto con nome e data, non come promessa.

Come creare un piano di DR in sette passi

1. Eseguite una business impact analysis e una valutazione del rischio. È il primo passo di qualsiasi iniziativa di DR. Elencate i processi aziendali, quanto costa un'interruzione all'ora e di quali sistemi ha bisogno ciascuno.
2. Fissate RTO e RPO per sistema. Raggruppate i sistemi in tre o quattro livelli, così progettate per livelli e non per centinaia di singoli server.
3. Scegliete una strategia per livello. Abbinate ogni livello a backup e ripristino, pilot light, warm standby o active/active. Verificate il costo rispetto all'impatto misurato nel passo 1.
4. Costruite la capacità tecnica. Backup, copie cross-region o cross-account, replica, infrastructure as code, monitoraggio e alerting anche nell'ambiente di ripristino.
5. Scrivete i runbook. Passaggi brevi e numerati che un ingegnere reperibile può seguire alle 03:00, incluso il failback.
6. Testate e correggete. Iniziate con un'esercitazione tabletop, poi test di ripristino, poi un failover. Registrate RTO e RPO misurati.
7. Mantenetelo. Rivedetelo almeno una volta all'anno e dopo ogni modifica significativa a sistemi, fornitori o organizzazione.

Disaster recovery per incidenti informatici e ransomware

Per molte aziende il disastro per cui devono davvero pianificare è un ransomware o un account amministratore compromesso, più che un'alluvione. Questo cambia il piano in tre modi.

• La replica non basta. AWS avverte che la replica continua "potrebbe non proteggere da eventi disastrosi come la corruzione dei dati o attacchi malevoli (come la cancellazione non autorizzata dei dati) tanto quanto i backup point-in-time." Conservate backup point-in-time che gli aggressori non possano cancellare, idealmente in un account separato con credenziali diverse.
• Il ripristino inizia dopo il contenimento. Il piano di incident response decide quando l'ambiente è abbastanza pulito per ripristinarvi i dati. Ripristinare su un'infrastruttura compromessa la reinfetta.
• L'identità è una dipendenza. Se il vostro identity provider o il password manager è fermo o compromesso, i runbook devono spiegare come i responsabili ottengono l'accesso.

Quando si attiva un piano di DR?

Il piano si attiva quando un'interruzione supera, o supererà chiaramente, ciò che la normale gestione degli incidenti può risolvere entro l'RTO. Scrivete i criteri, ad esempio "region primaria non disponibile per più di 30 minuti" o "dati di produzione cifrati da ransomware", e indica chi decide. Leggete quando attivare un piano di disaster recovery per i fattori scatenanti tipici.

Con quale frequenza testare un piano di DR?

Testate almeno una volta all'anno e dopo ogni modifica significativa. I sistemi critici meritano esercitazioni più frequenti. La policy di contingenza di esempio del NIST afferma che le capacità di ripristino "devono essere testate annualmente", e la guida raccomanda di rivedere il piano "almeno annualmente" e dopo modifiche significative.

Il NIST adatta inoltre la profondità del test al livello di impatto del sistema. Per i sistemi a basso impatto basta un'esercitazione tabletop; i sistemi a impatto moderato richiedono un'esercitazione funzionale che includa il ripristino da backup; i sistemi ad alto impatto richiedono un'esercitazione funzionale su larga scala che includa "un failover del sistema verso la sede alternativa."

La colonna della frequenza è una nostra raccomandazione per un'azienda media tipica; la vostra autorità di controllo o i vostri clienti possono richiedere di più. AWS riassume perché il test conta: "l'unico ripristino da errori che funziona è il percorso che testate frequentemente." Dopo ogni test, registrate il tempo di ripristino e la perdita di dati misurati, confrontateli con gli obiettivi e assegnate un responsabile a ogni lacuna.

NIS2 e legge svedese sulla cybersicurezza

Per le organizzazioni rientranti nell'ambito della NIS2, il disaster recovery non è più una buona pratica facoltativa. L'articolo 21, paragrafo 2, lettera c) della direttiva (UE) 2022/2555 (NIS2) richiede che le misure di gestione del rischio comprendano almeno "la continuità operativa, come la gestione dei backup e il ripristino in caso di disastro, e la gestione delle crisi". L'articolo 23 aggiunge le scadenze di segnalazione per gli incidenti significativi: un preallarme entro 24 ore da quando se ne ha conoscenza e una notifica dell'incidente entro 72 ore. Il vostro piano di DR e il vostro processo di segnalazione degli incidenti devono quindi funzionare insieme.

In Svezia la NIS2 è attuata dalla legge sulla cybersicurezza (Cybersäkerhetslag, SFS 2025:1506), entrata in vigore il 15 gennaio 2026. Il capitolo 2, sezione 3 elenca "kontinuitetshantering och krishantering" (gestione della continuità e gestione delle crisi) tra le misure di sicurezza minime. Aspettatevi che le autorità di vigilanza chiedano evidenze: un piano aggiornato, rapporti dei test e rilievi chiusi.

Come vi aiuta Opsio

Opsio progetta, gestisce e testa il DR per workload su AWS e Azure nell'ambito del proprio servizio di cloud disaster recovery.

Domande frequenti

Quali sono i componenti chiave di un piano di disaster recovery?

I componenti principali sono una business impact analysis e una valutazione del rischio, RTO e RPO per sistema, una strategia di ripristino per livello, backup e replica, criteri di attivazione, ruoli e contatti, runbook passo passo incluso il failback, un piano di comunicazione e un calendario di test e manutenzione.

Qual è il primo passo di un'iniziativa di disaster recovery?

Il primo passo è una business impact analysis abbinata a una valutazione del rischio. Vi dice quali processi e sistemi contano di più e per quanto tempo possono restare fermi, fissando RTO e RPO da cui dipende ogni decisione successiva.

Con quale frequenza va testato un piano di disaster recovery?

Almeno una volta all'anno e dopo ogni modifica importante a sistemi o fornitori. Eseguite esercitazioni tabletop per tutti i piani e test di ripristino o failover per i sistemi critici, come raccomanda NIST SP 800-34 per i sistemi a impatto più alto.

Qual è la differenza tra disaster recovery e business continuity?

Il disaster recovery ripristina sistemi IT e dati. La business continuity mantiene operativa l'azienda durante un'interruzione e copre anche persone, sedi, fornitori e comunicazione. Il piano di DR dovrebbe far parte del piano di business continuity.

Quali sono le quattro strategie di disaster recovery nel cloud?

Backup e ripristino, pilot light, warm standby e multi-site active/active. Vanno da ore di tempo di ripristino al costo più basso a un ripristino quasi in tempo reale al costo più alto, secondo il whitepaper di AWS sul DR.

La NIS2 richiede la pianificazione del disaster recovery?

L'articolo 21, paragrafo 2, lettera c) della NIS2 richiede che i soggetti essenziali e importanti coprano la continuità operativa, "come la gestione dei backup e il ripristino in caso di disastro, e la gestione delle crisi". In pratica significa una capacità di DR documentata e testata, che potete mostrare all'autorità di vigilanza.