Disaster Recovery: cos’è, come funziona e come costruire un piano efficace

Un guasto hardware, un attacco ransomware, un incendio in sala server: sono tutti eventi diversi, ma hanno una cosa in comune. Se la tua azienda non ha un piano per reagire, ogni ora di fermo si traduce in produttività persa, clienti non serviti e, nei casi più gravi, dati che non tornano indietro. Il disaster recovery è la disciplina che si occupa esattamente di questo: far ripartire i sistemi IT dopo un evento che li ha compromessi.

Cos'è il disaster recovery

Il disaster recovery è l'insieme di processi, procedure e tecnologie che permettono a un'azienda di ripristinare sistemi, dati e operatività IT dopo un evento imprevisto: guasti hardware, attacchi informatici, errori umani, calamità naturali o blackout prolungati. Non riguarda solo la tecnologia in sé, ma anche le decisioni organizzative su cosa ripristinare per primo, chi se ne occupa e in quanto tempo.

È un aspetto specifico della sicurezza informatica, distinto ma complementare alla business continuity, di cui parliamo tra poco.

Perché conta davvero

Il costo di un'interruzione non si misura solo in ore di lavoro perse. Secondo un'indagine internazionale di Uptime Institute, oltre metà dei data center che hanno subito un guasto importante negli ultimi anni ha stimato il danno oltre i 100.000 dollari, e circa uno su sei è andato oltre il milione. Gartner, dal canto suo, stima il costo medio di un fermo IT in circa 5.600 dollari al minuto: bastano pochi minuti per superare quello che molte PMI italiane spendono in un mese di manutenzione informatica.

Ma il danno economico diretto è solo una parte del problema. Un cliente che non riesce a ricevere un ordine, un fornitore che non trova risposta, un contratto con SLA che salta: sono conseguenze che si vedono settimane dopo, quando ormai i sistemi sono tornati su ma la fiducia no. Le aziende che non hanno mai testato un piano di ripristino, poi, lo scoprono quasi sempre nel momento peggiore: durante l'incidente vero, quando non c'è più tempo per improvvisare e ogni decisione va presa sotto pressione.

Cosa può causare un disastro informatico

Il termine "disastro" fa pensare subito a un terremoto o un incendio, ma nella pratica la causa più comune, oggi, è tutt'altra: il ransomware. Un attacco che cifra i dati aziendali e chiede un riscatto può bloccare un'azienda in pochi minuti, ed è ormai lo scenario che guida la maggior parte dei piani di disaster recovery scritti negli ultimi anni.

Poi ci sono i guasti hardware, banali ma frequenti: un disco che si rompe, un server che non riparte dopo un aggiornamento. L'errore umano resta una delle cause più sottovalutate, un file cancellato per sbaglio, una configurazione di rete modificata senza testarla prima. E infine gli eventi fisici, dagli allagamenti ai blackout prolungati: meno frequenti, ma capaci di mettere fuori uso un'intera sede in un colpo solo.

Un buon piano di disaster recovery non si concentra su un solo scenario. Si costruisce pensando a cosa succede ai sistemi, non a cosa li ha colpiti: che sia un ransomware o un fulmine, il problema da risolvere è lo stesso, riportare online quello che serve, nei tempi che l'azienda può permettersi.

Disaster recovery e business continuity: la differenza

Sono due termini che vengono spesso usati come sinonimi, ma non lo sono. La business continuity riguarda tutto ciò che serve a un'azienda per continuare a operare di fronte a qualsiasi tipo di interruzione, anche non legata all'IT: pensa alle dimissioni improvvise di un team chiave, o all'impossibilità di raggiungere la sede. Il disaster recovery è più specifico: si concentra sul ripristino dei sistemi informativi dopo un evento che li ha colpiti direttamente.

In pratica, il disaster recovery è una componente del piano di business continuity più ampio, quella che si occupa della parte IT. Un'azienda solida ha bisogno di entrambi, ma il disaster recovery è quello che entra in gioco per primo quando il problema è tecnico.

RTO e RPO: i due numeri che definiscono un piano

Qualunque strategia di disaster recovery si costruisce intorno a due parametri.

Il Recovery Time Objective (RTO) è il tempo massimo che puoi permetterti di restare fermo prima che i sistemi tornino operativi. Il Recovery Point Objective (RPO) è la quantità massima di dati che accetti di perdere, misurata in tempo: se il tuo RPO è un'ora, nel peggiore dei casi perderai il lavoro dell'ultima ora prima dell'incidente.

Non esiste un RTO o un RPO "giusto" in generale: dipende da quanto costa alla tua azienda un'ora di fermo, e da quali sistemi sono davvero critici rispetto a quelli che possono aspettare. Se vuoi vedere come questi due parametri si traducono in una soluzione concreta, li abbiamo approfonditi nella pagina dedicata al Disaster Recovery as a Service.

Come si costruisce un piano di disaster recovery

Un piano di disaster recovery parte sempre da un'analisi: capire quali sistemi sono critici, quanto costerebbe perderli anche solo per un'ora, e chi in azienda deve fare cosa quando qualcosa va storto. Questa fase di analisi si chiama Business Impact Analysis.

Una volta definite le priorità, si stabiliscono RTO e RPO per ogni sistema, si sceglie la soluzione tecnica più adatta, e si testa il piano periodicamente, perché un piano mai testato è, nella pratica, solo un documento. Se cerchi un percorso pratico passo per passo, lo trovi nella nostra guida 5 consigli per un piano di disaster recovery.

Le strategie di disaster recovery: tradizionale, cloud, DRaaS

Storicamente, il disaster recovery si costruiva con un secondo sito fisico, spesso di proprietà della stessa azienda: server duplicati, ospitati in un'altra sede, pronti a entrare in funzione. Funziona, se qualcuno lo mantiene aggiornato e lo testa davvero. Ma è caro: bisogna comprare hardware che nella maggior parte dei casi resta spento, pagare uno spazio che lo ospiti, e avere qualcuno che sappia farlo ripartire quando serve. E anche quando tutto è pronto, attivarlo richiede tempo, spesso ore.

Il cloud ha cambiato le carte in tavola. Invece di comprare un secondo sito, si replica su un'infrastruttura che qualcun altro gestisce e mantiene, pagando in base a quanto la si usa davvero: meno capitale immobilizzato, tempi di attivazione molto più brevi, e la scalabilità non è più un problema tuo.

La forma più completa di questo approccio è il Disaster Recovery as a Service (DRaaS): non ti limiti a replicare i dati su uno storage esterno, un fornitore terzo si prende in carico l'intera catena, replica, failover, ripristino, con un contratto che stabilisce chiaramente RTO e RPO invece di lasciarli alla buona volontà di chi gestisce l'infrastruttura interna. È la differenza tra avere un'assicurazione scritta sulla carta e avere qualcuno che risponde davvero quando succede qualcosa.

Domande frequenti

Il disaster recovery è la stessa cosa dell'alta disponibilità?

No, anche se sono spesso confusi. L'alta disponibilità serve a evitare le interruzioni, mantenendo i sistemi attivi anche in caso di guasti minori. Il disaster recovery entra in gioco quando l'interruzione è già avvenuta ed è più grave. Ne parliamo più nel dettaglio in Alta disponibilità vs sistemi tradizionali.

Ogni azienda ha bisogno di un piano di disaster recovery?

Sì, anche le piccole realtà. Cambia la complessità della soluzione, non la necessità: più un'azienda dipende dai propri sistemi IT per operare, più un'interruzione prolungata pesa.

Quanto spesso va testato un piano di disaster recovery?

Almeno una o due volte l'anno, o ogni volta che cambia in modo significativo l'infrastruttura che il piano deve proteggere. Un piano non testato è un piano di cui non sai se funziona davvero.

Backup e disaster recovery sono la stessa cosa?

No. Il backup protegge i dati. Il disaster recovery protegge anche la capacità di continuare a lavorare, replicando sistemi e applicazioni, non solo le informazioni.