Disaster recovery per le PMI:
dal piano al ripristino

In breve: il disaster recovery (DR) è la capacità di rimettere in funzione sistemi e processi dopo un evento grave — un guasto, un errore umano, un ransomware. Non coincide con il backup: le copie sono solo un pezzo. Quello che fa la differenza è un piano misurato da due numeri — RPO (quanti dati puoi perdere) e RTO (in quanto tempo riparti) — e soprattutto testato. E attenzione: l’RTO che dichiari non è quello che vivrai davvero. Ecco cosa serve a una PMI, senza tecnicismi inutili.

Backup, disaster recovery e alta disponibilità: non sono la stessa cosa

Sono tre concetti che vengono spesso confusi, e la confusione costa cara quando serve davvero. Il backup è la copia dei dati che permette di recuperarli dopo una cancellazione, un guasto o un attacco. Il disaster recovery è l’insieme di piano, procedure e risorse che riporta in funzione i sistemi e i processi dopo un evento grave. L’alta disponibilità (HA) serve invece a evitare il fermo grazie alla ridondanza, ma è un’altra cosa ancora.

La distinzione più importante è questa: l’alta disponibilità non protegge dal ransomware né dalla cancellazione logica. Se un sistema viene cifrato o un dato viene cancellato per errore, la ridondanza sincrona propaga il problema istantaneamente alla copia. Per questo il backup e il disaster recovery restano indispensabili anche quando l’infrastruttura è ridondata: rispondono a domande diverse.

I due numeri che governano tutto: RPO e RTO

Un piano di disaster recovery si misura con due parametri. L’RPO (Recovery Point Objective) è la quantità massima di dati che puoi permetterti di perdere, espressa in tempo: se fai backup ogni 24 ore, nel peggiore dei casi perdi un giorno di lavoro. L’RTO (Recovery Time Objective) è il tempo massimo entro cui devi tornare operativo dopo l’incidente.

Il punto chiave è che RPO e RTO si definiscono per ciascun sistema, in base alla sua criticità. Il gestionale che ferma la produzione avrà un RPO e un RTO di poche ore; un archivio documentale storico può tollerare un giorno o più. Sono questi due numeri a dire quanto investire in backup e ridondanza — non il contrario. Definirli è una scelta di business prima che tecnica: quantificano quanto vale, in tempo e dati, ogni processo aziendale.

L’RTO sulla carta quasi sempre mente

C’è uno scarto sistematico tra l’RTO scritto nel piano e il tempo di ripristino reale. Due ragioni, quasi mai messe nero su bianco, lo fanno saltare.

La prima è aritmetica. Un RTO di 4 ore convive spesso con backup da decine di terabyte e una linea da poche centinaia di Mbit/s: ripristinare 20 TB su un collegamento da 200 Mbps richiede giorni, non ore, per pura fisica del trasferimento. Il numero sul piano resta 4; il cronometro dice nove giorni. È il calcolo che nessuno fa in fase di pianificazione — e cambia tutto: per RTO bassi servono copie locali veloci, repliche già pronte o seeding fisico, non soltanto un backup «in cloud».

La seconda è forense. In un attacco ransomware gli aggressori restano in rete settimane prima di cifrare. L’ultimo backup «sano» contiene già la loro backdoor: ripristinarlo significa rimettere in produzione anche l’attaccante. La domanda vera non è «ho il backup?» ma «fino a quando devo tornare indietro per trovarne uno pulito?». Individuare quel punto richiede analisi, e mentre lo cerchi l’RTO reale si allontana dalle ore promesse. Per questo contano una cronologia lunga dei punti di ripristino e la capacità di verificare un backup prima di fidarsene.

Cosa contiene davvero un piano di DR

Un piano di disaster recovery non è un documento da cassetto: è ciò che permette a persone sotto stress di agire in modo coordinato. Gli elementi che non possono mancare:

• 1Inventario e priorità— quali sistemi e processi sono critici, in che ordine vanno ripristinati, con quali RPO e RTO.
• 2Scenari di rischio— guasto hardware, errore umano, ransomware, disastro del sito: ognuno richiede una risposta diversa.
• 3Ruoli e responsabilità— chi decide, chi esegue, chi comunica. Senza ruoli chiari, il piano si blocca al primo imprevisto.
• 4Runbook operativi— le procedure passo-passo di ripristino, scritte in modo che siano eseguibili anche da chi non le ha redatte.
• 5Risorse di ripristino e comunicazione — dove si ripristina (sito alternativo, datacenter o cloud) e come si informano clienti, fornitori ed eventualmente le autorità.
• 6Test periodico— l’elemento più trascurato e più importante: un piano mai provato è un’ipotesi, non una garanzia.

Il ripristino dopo un ransomware: la prova del nove

Il ransomware è lo scenario che mette alla prova un piano di DR come nessun altro, perché attacca proprio le copie. Gli aggressori cercano e cifrano i backup raggiungibili dalla rete prima di colpire i sistemi: se le tue copie sono online e accessibili con le stesse credenziali dell’infrastruttura, non sono una garanzia.

Le contromisure che cambiano l’esito: backup immutabili (non modificabili né cancellabili per un periodo definito, neppure da un amministratore), copie offline o air-gapped, credenziali separate dal dominio di produzione, e un ordine di ripristino definito (prima identità e domain controller, poi i sistemi critici). Conta anche la velocità operativa: nel cloud, strumenti come il ripristino massivo (bulk restore) delle macchine virtuali permettono di rimettere in piedi decine di server in parallelo invece che uno alla volta. E prima di tutto: verificare che i backup non siano già compromessi. Su questo fronte un servizio di gestione degli incidenti fa la differenza tra un fermo di ore e uno di settimane.

Il disaster recovery nel cloud per le PMI

Il cloud è un ottimo abilitatore del disaster recovery, ma non lo sostituisce. Azure Backup offre copie immutabili e soft-delete; Azure Site Recovery replica le macchine virtuali su una region diversa e permette il failover; e i dati di Microsoft 365 restano tuoi e vanno protetti con un backup dedicato — il modello di responsabilità condivisa lascia a te la protezione dei dati, non al provider.

Per una PMI la scelta sensata è spesso un disaster recovery gestito: definizione di RPO e RTO per processo, backup immutabili, replica della virtualizzazione su datacenter europei e test documentati. È anche il modo più lineare per soddisfare i requisiti di continuità previsti da NIS2 e GDPR senza costruire e mantenere tutto internamente.

AtWorkStudio opera da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, qualificati ACN (Agenzia per la Cybersicurezza Nazionale) per i servizi cloud, membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.