Un guasto ai server, un attacco ransomware, un allagamento nella sala macchine: sono eventi rari, ma quando accadono il costo non si misura in hardware da sostituire, bensì in giorni di attività ferma. Il disaster recovery è l’insieme di procedure, tecnologie e infrastrutture che permette a un’azienda di rimettere in funzione i propri sistemi informatici dopo un evento critico, in tempi definiti e prevedibili. Non è un prodotto che si acquista una volta, ma un piano che si progetta, si documenta e si collauda periodicamente.

In questa guida vediamo che cos’è il disaster recovery, come si costruisce un piano concreto, quali parametri ne definiscono la qualità e quali soluzioni sono realisticamente alla portata di una PMI.

Che cos’è il disaster recovery e perché riguarda ogni azienda

Il disaster recovery è il processo di ripristino di dati, applicazioni e infrastrutture IT dopo un evento che ne ha compromesso il funzionamento. L’obiettivo non è impedire il disastro, ma ridurre a un intervallo noto e accettabile il tempo che separa il guasto dal ritorno alla piena operatività.

La differenza rispetto a un semplice backup sta nell’ampiezza: il backup conserva una copia dei dati, il disaster recovery risponde alla domanda “come torniamo a lavorare”. Include quindi le procedure di ripristino, l’infrastruttura alternativa su cui far ripartire i sistemi, la catena delle responsabilità e i tempi previsti per ogni fase.

Molte piccole e medie imprese considerano il tema una prerogativa delle grandi organizzazioni. È un equivoco costoso: proprio le realtà più piccole hanno margini di resistenza inferiori, perché spesso l’intera operatività dipende da un unico server, da un gestionale e da una connessione. Per una PMI manifatturiera con la produzione legata al gestionale, ogni giorno di fermo si traduce in ordini non evasi e consegne slittate.

Quali eventi rendono necessario un piano di ripristino

Le cause che portano all’attivazione di un piano di disaster recovery sono più ordinarie di quanto suggerisca il termine “disastro”. Nella maggior parte dei casi non si tratta di eventi catastrofici, ma di guasti hardware, errori umani e attacchi informatici.

Le categorie principali sono quattro:

• Guasti tecnici: rottura di dischi, controller RAID, alimentatori o gruppi di continuità; corruzione di database o file system.
• Attacchi informatici: ransomware che cifra i dati aziendali, cancellazioni malevole, compromissione delle credenziali amministrative.
• Errori umani: eliminazioni accidentali, aggiornamenti mal riusciti, configurazioni errate applicate in produzione.
• Eventi ambientali e logistici: incendi, allagamenti, blackout prolungati, indisponibilità della sede.

Il ransomware merita una nota a parte. È oggi la causa più frequente di attivazione dei piani di ripristino e ha una caratteristica insidiosa: colpisce anche i backup raggiungibili dalla rete. Un piano progettato senza copie isolate o immutabili rischia di rivelarsi inutile proprio nello scenario più probabile.

Quanto costa davvero un fermo dei sistemi informatici

La domanda che precede ogni decisione di investimento è quanto costi un’ora di inattività. Il calcolo è meno astratto di quanto sembri e si compone di voci che ogni azienda può stimare con buona approssimazione a partire dai propri numeri di bilancio.

La prima voce è il costo del personale fermo: retribuzione oraria lorda moltiplicata per le persone che non possono lavorare. La seconda è il margine perso sulla produzione o sulle vendite non realizzate nel periodo di blocco. La terza, spesso la più pesante, raccoglie le conseguenze indirette: penali contrattuali per consegne mancate, ordini dirottati sulla concorrenza, costi di recupero con straordinari e lavorazioni urgenti.

A queste si aggiungono le voci difficili da quantificare ma reali, come il danno reputazionale verso clienti che hanno subito il disservizio e, nel caso di violazioni di dati personali, gli obblighi di notifica al Garante entro settantadue ore previsti dal GDPR.

Il confronto tra questa cifra e il costo annuo di una soluzione di ripristino ribalta la prospettiva abituale. Per molte PMI il canone di un servizio gestito equivale al margine perso in una o due giornate di fermo: l’investimento si giustifica anche ipotizzando un solo episodio critico nell’arco di diversi anni.

Come funziona un piano di disaster recovery

Un piano di disaster recovery è un documento operativo che stabilisce chi fa cosa, in quale ordine e con quali strumenti nel momento in cui i sistemi si fermano. Deve essere abbastanza dettagliato da essere eseguibile sotto pressione, anche da un tecnico che non lo ha scritto.

Le componenti essenziali sono l’inventario dei sistemi critici, la classificazione per priorità di ripristino, le procedure tecniche passo per passo, i riferimenti delle persone coinvolte e i criteri per dichiarare conclusa l’emergenza. Un piano che si limita a indicare dove sono i backup non è un piano di disaster recovery.

La costruzione parte sempre da un’analisi di impatto: quali processi aziendali si fermano se cade un determinato sistema, e quanto costa ogni ora di indisponibilità. Da qui discendono le priorità e il livello di investimento giustificato. Abbiamo raccolto la metodologia completa, con un esempio di struttura documentale, nella guida su come si scrive un disaster recovery plan.

RTO e RPO: i due parametri che definiscono il livello di protezione

RTO e RPO sono le due misure che traducono in numeri le aspettative di ripristino. Sono il linguaggio con cui la direzione aziendale e i tecnici si accordano su quanto downtime e quanta perdita di dati siano accettabili, e determinano l’architettura e il costo della soluzione.

Il RTO (Recovery Time Objective) è il tempo massimo entro cui un sistema deve tornare operativo. Se il RTO del gestionale è di quattro ore, l’infrastruttura deve permettere di riavviarlo entro quel limite.

Il RPO (Recovery Point Objective) è la quantità massima di dati che l’azienda accetta di perdere, espressa in tempo. Un RPO di un’ora significa che, nel caso peggiore, si perdono i dati dell’ultima ora di lavoro: le copie devono quindi essere prodotte almeno ogni ora.

Questi due valori vanno definiti per ciascun sistema, non per l’azienda nel suo insieme. Il gestionale della produzione e l’archivio storico dei documenti hanno esigenze molto diverse, e applicare a tutto il parametro più stringente porta a costi ingiustificati.

Disaster recovery e business continuity: due piani che lavorano insieme

I due termini vengono spesso usati come sinonimi, ma descrivono ambiti distinti. La business continuity riguarda l’intera azienda e stabilisce come continuare a operare durante l’emergenza; il disaster recovery è la sua componente tecnologica e si occupa del ripristino dei sistemi IT.

Un piano di continuità operativa comprende anche le sedi alternative, le procedure manuali di emergenza, la comunicazione verso clienti e fornitori, la gestione del personale. Il disaster recovery ne è il capitolo informatico, ma senza il contesto più ampio rischia di ripristinare sistemi corretti nei tempi sbagliati rispetto alle reali priorità del business.

Per le PMI l’approccio più efficace è partire dal disaster recovery, che ha confini tecnici chiari e risultati misurabili, ed estenderlo progressivamente. Il rapporto tra i due piani e i criteri per integrarli sono trattati nell’approfondimento su differenze e integrazione tra disaster recovery e business continuity.

Backup e disaster recovery non sono la stessa cosa

Il backup è una condizione necessaria ma non sufficiente. Conserva le copie dei dati; il disaster recovery garantisce che quelle copie siano ripristinabili su un’infrastruttura funzionante, entro i tempi stabiliti e con procedure verificate.

La distinzione diventa evidente in caso di guasto grave. Disporre di un backup completo su NAS non aiuta se il server su cui ripristinarlo è distrutto, se non esiste hardware alternativo e se il ripristino di alcuni terabyte richiede due giorni contro un RTO di quattro ore. Il dato c’è, l’operatività no.

Una strategia solida combina tre elementi: copie multiple secondo la regola 3-2-1 (tre copie, due supporti diversi, una fuori sede), almeno una copia immutabile o isolata dalla rete per resistere al ransomware, e un’infrastruttura di ripartenza già predisposta. Su questo si innestano le soluzioni di disaster recovery e backup gestite da HkStyle.

Disaster recovery in cloud e soluzioni DRaaS

Il cloud ha reso accessibile alle PMI un livello di protezione che in passato richiedeva una seconda sala server. Con il disaster recovery in cloud le copie e le repliche dei sistemi risiedono presso un data center esterno, pronte a essere riattivate senza dipendere dalla sede aziendale.

Il modello DRaaS, Disaster Recovery as a Service, porta l’idea alle conseguenze naturali: l’infrastruttura di ripristino viene erogata come servizio in abbonamento, con costi ricorrenti prevedibili al posto dell’investimento in hardware duplicato. Il fornitore mantiene le repliche aggiornate e garantisce contrattualmente i tempi di riattivazione.

Il vantaggio principale è economico: si paga la capacità di ripartire, non l’hardware fermo in attesa di un evento che potrebbe non arrivare mai. Vantaggi, limiti e criteri di scelta sono analizzati nella pagina dedicata al Disaster Recovery as a Service per le PMI.

Le soluzioni cloud di HkStyle: copie dei dati costruite sulle esigenze dell’azienda

Non tutte le aziende hanno lo stesso RTO, lo stesso volume di dati o lo stesso budget, per questo HkStyle non propone un’unica architettura standard ma progetta ogni soluzione cloud su misura, a partire dal contesto specifico del cliente. Il backup in cloud per aziende replica in modo automatico file e sistemi su server remoti ad alta affidabilità, con architetture configurate dai tecnici HkStyle e soluzioni di backup esterno sviluppate ad hoc in base alle esigenze specifiche del cliente, per la gestione di copie e repliche incrementali. Quando la sola replica dei dati non basta e serve anche l’infrastruttura su cui farli ripartire, la soluzione si estende ai servizi di cloud aziendale full o hybrid, con risorse IaaS, PaaS o SaaS erogate su hardware enterprise di proprietà HkStyle: l’azienda sceglie quanta parte dell’infrastruttura mantenere in sede e quanta spostare in cloud, in base ai propri RTO e RPO.

Un caso reale: dal furto dei server al ritorno in operatività

Il valore di questo approccio si vede negli scenari concreti. Un cliente HkStyle ha subito il furto fisico dei server in sede: senza una copia dei dati fuori dall’azienda, un evento simile azzera l’infrastruttura informatica insieme all’hardware sottratto. Grazie al backup in cloud già attivo e a un piano di disaster recovery strutturato, il cliente ha potuto ripristinare l’operatività senza dover ricostruire da zero dati e configurazioni, dimostrando nella pratica perché la copia dei dati non deve mai dipendere solo dai sistemi fisici della sede.

Un principio confermato anche in un altro intervento reale di HkStyle, quello su un CED allagato: con l’infrastruttura fisica del data center temporaneamente inutilizzabile, i server sono stati riavviati direttamente da ambienti cloud, garantendo l’accesso ai servizi essenziali mentre la sede veniva ripristinata. Altri casi applicativi, con maggiori dettagli su contesto e risultati, sono raccolti nella sezione Casi di Successo di HkStyle.

Come si attiva e si collauda un piano di disaster recovery

Cosa succede nelle prime ore di un’emergenza

Nel momento in cui i sistemi si fermano, l’efficacia del piano dipende dalla chiarezza della sequenza operativa. Le prime ore sono decisive e devono seguire un ordine stabilito in anticipo, non decisioni improvvisate sotto pressione.

La sequenza tipica prevede quattro fasi. Il rilevamento, in cui il monitoraggio o le segnalazioni degli utenti evidenziano l’anomalia. La valutazione, che stabilisce natura ed estensione del problema e determina se attivare formalmente il piano: è il passaggio più delicato, perché di fronte a un ransomware occorre isolare i sistemi prima di qualsiasi tentativo di ripristino, per evitare di reinfettare l’ambiente ricostruito.

Segue il ripristino vero e proprio, che procede per priorità decrescente secondo l’ordine fissato nel piano, e infine il rientro in esercizio, con la verifica dell’integrità dei dati, la riconciliazione delle operazioni svolte manualmente durante il fermo e la comunicazione di chiusura.

Un elemento spesso sottovalutato è la catena decisionale. Il piano deve indicare con nome e recapito chi ha l’autorità di dichiarare l’emergenza e chi lo sostituisce in caso di assenza. Nelle organizzazioni piccole questa figura coincide spesso con l’imprenditore, che però potrebbe non essere raggiungibile: prevedere una delega esplicita evita ore di attesa nel momento peggiore.

Perché un piano non collaudato non è un piano

Un piano di disaster recovery mai testato ha un valore puramente documentale. Il collaudo periodico è ciò che distingue una procedura funzionante da un documento archiviato, e in genere è la fase che le aziende trascurano di più.

I test si articolano su livelli crescenti di realismo: la revisione a tavolino delle procedure con le persone coinvolte, il ripristino di singoli sistemi in ambiente isolato, la simulazione completa con riattivazione dell’infrastruttura secondaria. Una cadenza ragionevole per una PMI prevede una verifica dei ripristini ogni trimestre e una simulazione estesa una volta l’anno.

Il test serve soprattutto a far emergere ciò che la documentazione non prevede: credenziali scadute, licenze legate all’hardware originale, dipendenze fra applicativi non mappate, tempi di trasferimento sottostimati. Sono dettagli che in emergenza trasformano quattro ore di ripristino previste in due giorni di fermo reale. Ogni test va chiuso con un aggiornamento del piano.

Il disaster recovery per le PMI in Lombardia

Per le imprese lombarde il disaster recovery si intreccia con caratteristiche specifiche del territorio: forte concentrazione manifatturiera, filiere integrate in cui il fermo di un fornitore si propaga a valle, e una crescente richiesta di garanzie di continuità nei contratti con i clienti finali.

A questo si aggiunge la spinta normativa. La direttiva NIS2 estende gli obblighi di gestione del rischio informatico e di continuità operativa a una platea molto più ampia di imprese rispetto al passato, includendo numerose realtà di media dimensione e i loro fornitori. Disporre di un piano documentato e collaudato diventa un requisito contrattuale prima ancora che una scelta tecnica.

HkStyle progetta e gestisce piani di ripristino per aziende in Lombardia ed Emilia-Romagna, con certificazioni ISO 9001:2015 e ISO/IEC 27001:2022 a garanzia dei processi di gestione delle infrastrutture e della sicurezza delle informazioni. Le specificità del tessuto produttivo brianzolo sono approfondite nella pagina sul disaster recovery per le aziende di Monza e della Brianza.

Valutare il proprio livello di protezione richiede poche domande concrete: quanto tempo servirebbe oggi per rimettere in funzione il gestionale, quanti dati si perderebbero, chi eseguirebbe materialmente il ripristino e quando è stata l’ultima verifica. Se qualcuna di queste risposte non è immediata, il piano va costruito o rivisto. Contatta HkStyle per un’analisi dell’infrastruttura e la definizione di RTO e RPO adeguati alla tua attività.