Disaster Recovery: la guida completa per il 2026

TL;DR

Il Disaster Recovery è l'insieme di processi, persone e tecnologie che permettono a un'azienda di tornare operativa dopo un guasto grave dei sistemi IT. Si misura con due numeri: RTO (quanto tempo prima di tornare online) e RPO (quanti dati si possono perdere). Nel 2026, con NIS2 e ISO 27001:2022 ormai a regime, avere un piano DR scritto e testato non è più una "best practice": è un requisito di legge per molti settori. Questa guida copre tutto quello che serve per scegliere, dimensionare e mantenere un sistema DR serio.

Cosa è il Disaster Recovery

Il Disaster Recovery (DR) è la disciplina che si occupa del ripristino dell'infrastruttura IT dopo un evento disastroso. Per "evento disastroso" non si intende solo l'incendio del CED o l'alluvione: nove volte su dieci si tratta di ransomware, errore umano, guasto hardware o aggiornamento software andato male.

Il DR fa parte di una disciplina più ampia, il Business Continuity & Disaster Recovery (BCDR), che riguarda anche persone, processi, fornitori e comunicazione. Il DR è la fetta tecnica: come faccio ripartire i sistemi.

Una distinzione utile: backup ≠ disaster recovery. Il backup è una copia dei dati. Il DR è l'insieme di automazioni, configurazioni, runbook e infrastrutture che trasforma quella copia in un sistema funzionante. Avere il backup senza il DR è come avere un airbag senza la cintura: meglio di niente, ma non basta.

I numeri che contano: RTO e RPO

Ogni progetto DR ruota attorno a due numeri.

• RTO (Recovery Time Objective) — il tempo massimo accettabile fra l'evento disastroso e il ritorno alla normalità. Un RTO di 15 minuti significa che 15 minuti dopo il disastro il sistema deve essere di nuovo usabile.
• RPO (Recovery Point Objective) — la quantità massima di dati che si è disposti a perdere. Un RPO di 5 minuti significa che, nel peggiore dei casi, si perdono solo gli ultimi 5 minuti di lavoro.

Più piccoli sono questi due numeri, più costa il DR. La prima cosa da fare in un progetto è quindi una Business Impact Analysis (BIA): per ogni applicazione critica, quanti minuti di fermo sopporta l'azienda, quanto costano (in euro al minuto), e quanti dati può effettivamente perdere senza dover rifare un giorno di lavoro a mano.

Le architetture DR principali

Esistono cinque architetture DR canoniche, ordinate per RTO crescente.

1. Active-active multi-site — due CED in produzione contemporanea, traffico bilanciato. RTO sub-secondo, costo molto alto. Tipico di banche e telco.
2. Hot standby — secondo sito sempre acceso, con replica continua. RTO da pochi secondi a un minuto.
3. Warm standby — VM pronte ma spente, dati replicati. RTO di pochi minuti. Il sweet spot di Sefthy.
4. Cold standby — backup off-site, infrastruttura da provisionare al disastro. RTO da ore a giorni.
5. Backup-only — la sola copia dei dati. Non è davvero DR, ma è il livello base per uscire da un ransomware.

La maggior parte delle PMI italiane ha bisogno di un warm standby per i sistemi core (gestionale, posta, file server) e un backup-only per il resto. Spendere per active-active su un'azienda da 80 dipendenti è quasi sempre overkill.

Cloud DR vs DR on-premises

Storicamente il DR si faceva con un secondo CED di proprietà. Nel 2026 il modello è cambiato:

• Cloud DR è quasi sempre più economico, perché si paga solo lo storage e si compute "scatta" solo durante il failover.
• È più semplice da testare: una VM cloud si accende, si verifica e si spegne.
• È più conforme a NIS2 e ISO 27001:2022, perché i provider seri (con almeno ISO 27001 + 27017 + 27018) trasferiscono al cliente metà del lavoro di evidenza.

Quando ha ancora senso un secondo CED on-prem? In due casi: settori con normative specifiche (difesa, sanità di livello 3), oppure quando l'RTO richiesto è sotto i 30 secondi e la latenza pubblica non è sufficiente.

Il problema del Layer 3 e perché esiste l'L2 tunnel

La maggior parte dei DR cloud lavora a Layer 3: la VM in cloud ottiene un nuovo IP, e per farla parlare con i client si usa una VPN site-to-site con NAT. Questo approccio funziona ma porta con sé problemi pesanti in scenario reale:

• Riconfigurazione DNS — i record A vanno cambiati. Il TTL precedente fa propagare la modifica in 15-60 minuti.
• Riconfigurazione di applicazioni con IP cablati — i gestionali pre-2010 hanno spesso IP scritti nel codice o in file di configurazione. Riconfigurarli sotto stress è una sorgente di errori.
• Riconfigurazione del firewall del cliente — regole pensate per un IP locale vanno riadattate per un IP cloud.

Sefthy usa un tunnel Layer 2 (un cavo ethernet virtuale) fra la rete del cliente e il datacenter. La VM in cloud parte con lo stesso IP, la stessa subnet e lo stesso broadcast domain della macchina originale. I client si riconnettono senza accorgersi di nulla. Niente DNS, niente NAT, niente riconfigurazione.

Come scegliere una soluzione DR

Una checklist breve per la selezione:

1. RTO e RPO realistici del fornitore, non quelli da brochure. Chiedete un caso reale documentato.
2. Numero di test inclusi nel canone. Il DR non testato non funziona. Sefthy include test trimestrali in tutti i piani.
3. Conformità del provider: ISO 27001:2022, ISO 27017, ISO 27018. Se manca anche solo la 27018, attenzione ai dati personali.
4. Sovranità dei dati. Per chi opera nel pubblico o in ambito NIS2, un cloud italiano (non solo "europeo") è un vantaggio competitivo nelle gare.
5. Modello di pricing trasparente. Diffidate dei "pay per restore" — in emergenza il conto può triplicare.

Cosa è cambiato nel 2026

Tre cose hanno reso il DR un tema di board, non più solo di IT:

• NIS2 — l'articolo 21 della direttiva impone misure di continuità operativa misurabili. Un piano DR scritto è il primo controllo che chiede ACN in caso di audit.
• Polizze cyber — le compagnie assicurative chiedono evidenza di DR testato per sottoscrivere una polizza. Senza test trimestrali, premi fino al 40% più alti.
• Aspettative dei clienti finali — un fermo di 6 ore di un e-commerce nel 2026 fa news. Nel 2018 era la norma.

Errori frequenti

I tre errori che vediamo più spesso:

• Dichiarare un RTO troppo basso in fase commerciale e non testarlo. Il giorno del disastro arrivano le sorprese.
• Confondere snapshot e DR. Lo snapshot è una foto del disco; senza un piano di ripartenza dello stack applicativo, è solo storage.
• Non includere i runbook. Il DR è anche organizzativo: chi fa cosa, in che ordine, con quali credenziali.

FAQ

Quanto costa un DR cloud per una PMI?

Per un'azienda con 5-15 server virtuali, un DR managed con RTO di 10 minuti parte intorno ai 300-700 euro al mese in Italia. La fascia bassa copre il backup-only, la fascia alta il warm standby con tunnel L2.

Ogni quanto va testato il DR?

ISO 27001:2022 controllo A.5.30 e NIS2 articolo 21 raccomandano almeno una volta l'anno un test completo. La pratica matura prevede un tabletop trimestrale e un full failover annuale.

Il DR sostituisce il backup?

No. Il DR usa il backup come ingrediente. Il backup garantisce l'esistenza del dato; il DR garantisce il ritorno operativo del servizio.

Quanto dura un'implementazione DR seria?

Con un fornitore esperto, un'azienda da 50-100 dipendenti completa l'onboarding (deploy, configurazione, primo test) in 5 giorni lavorativi. Sotto i 5 giorni si rischia di saltare la BIA; sopra le 3 settimane di solito significa che mancano stakeholder.

Vuoi vedere un piano DR concreto su misura per la tua azienda? Parla con uno specialista Sefthy o consulta il post di approfondimento su come calcolare il tuo RTO reale.