Un server bloccato dal ransomware, un guasto elettrico, un errore umano nella cancellazione dei dati: per una PMI il problema non è soltanto tecnico. Se non si ripristinano rapidamente gestionali, posta elettronica, file condivisi e sistemi di comunicazione, l’attività si ferma, le persone non lavorano e i clienti attendono risposte. Capire come pianificare disaster recovery aziendale significa definire prima dell’emergenza chi fa cosa, quali servizi ripartono per primi e in quanto tempo.

Il disaster recovery non coincide con il backup. Il backup conserva una copia dei dati; il disaster recovery stabilisce il percorso operativo per riportare in funzione l’ambiente IT dopo un incidente. La differenza è sostanziale: possedere copie di sicurezza non garantisce, da solo, di saperle recuperare, di avere credenziali disponibili o di ripristinare le applicazioni nell’ordine corretto.

Disaster recovery aziendale: da quali rischi partire

Un piano utile nasce dai rischi concreti dell’impresa, non da un documento standard. Un’azienda manifatturiera può dipendere dal gestionale di produzione e dalle postazioni di magazzino; uno studio professionale dalla disponibilità di documenti, posta e software contabili; un’impresa commerciale dall’e-commerce, dal centralino VoIP e dal CRM. Lo stesso guasto può quindi avere impatti molto diversi.

Il primo lavoro consiste nel mappare sistemi, dati, persone e fornitori che sostengono le attività quotidiane. Non basta elencare server e PC. Occorre capire quali processi restano fermi se un servizio non è disponibile per un’ora, un giorno o una settimana. Vanno considerate anche le dipendenze meno evidenti: connessione Internet, DNS, autenticazione utenti, licenze software, accessi cloud, firewall, backup e contatti di assistenza.

In questa fase è utile attribuire a ogni servizio una priorità aziendale. Il gestionale che blocca fatturazione e ordini avrà priorità diversa rispetto a un archivio storico consultato raramente. Questa distinzione evita due errori frequenti: investire in protezioni costose per sistemi marginali oppure scoprire troppo tardi che un servizio apparentemente secondario impedisce il ripristino di tutti gli altri.

Definire tempi e perdite accettabili

Due parametri rendono il piano misurabile. L’RTO, Recovery Time Objective, indica il tempo massimo accettabile per ripristinare un servizio. L’RPO, Recovery Point Objective, definisce invece quanta perdita di dati l’azienda può tollerare, misurata in tempo.

Per esempio, se l’RTO del gestionale è di quattro ore, l’organizzazione deve disporre di risorse, procedure e competenze per renderlo operativo entro quel limite. Se l’RPO è di un’ora, le copie o le repliche devono consentire di recuperare dati aggiornati almeno all’ora precedente all’incidente. Un backup notturno non risponde a questa esigenza, perché esporrebbe l’impresa alla perdita dell’intera giornata lavorativa.

Non esistono valori corretti in assoluto. Ridurre RTO e RPO comporta normalmente maggiori costi: infrastrutture ridondate, repliche più frequenti, servizi cloud, monitoraggio e assistenza specializzata. Per una piccola realtà, un ripristino entro il giorno successivo può essere sostenibile per alcuni archivi; per sistemi di vendita, produzione o assistenza clienti può essere necessario intervenire in poche ore. La scelta deve dipendere dal costo reale del fermo, non soltanto dal budget IT.

Come pianificare disaster recovery aziendale in modo operativo

Dopo la valutazione iniziale, il piano deve trasformarsi in istruzioni semplici e verificabili. In un’emergenza non c’è tempo per ricostruire a memoria configurazioni, cercare password o decidere chi può autorizzare il ripristino. Il documento deve essere accessibile anche se la rete aziendale non funziona, in una copia protetta esterna oppure in formato cartaceo conservato in luogo sicuro.

Una procedura efficace indica chi rileva l’incidente, chi coordina le attività tecniche, chi comunica con dipendenti, clienti e fornitori e chi prende le decisioni in caso di indisponibilità del titolare o del responsabile IT. Nelle PMI questi ruoli possono essere ricoperti da poche persone, ma devono essere nominati con chiarezza e avere un sostituto.

Il piano dovrebbe inoltre descrivere l’ordine di ripristino. In molti casi si parte da connettività, firewall, identità digitali e servizi di autenticazione; seguono server, dati, applicazioni e postazioni. Se si tenta di recuperare prima un’applicazione senza ripristinare le sue dipendenze, si allungano i tempi e aumentano gli errori. Per ogni sistema servono riferimenti precisi: posizione delle copie, modalità di accesso, configurazione necessaria, licenze, contatti del produttore e verifica finale da eseguire.

Anche la comunicazione merita una sezione dedicata. Durante un fermo, i collaboratori devono sapere quali strumenti possono ancora usare e quali comportamenti evitare. I clienti più coinvolti devono ricevere informazioni corrette, senza promesse irrealistiche. Un messaggio coordinato tutela la reputazione dell’impresa molto più di comunicazioni frammentarie o del silenzio.

Backup, cloud e copie immutabili: scegliere senza semplificazioni

La regola più nota parla di almeno tre copie dei dati, su due supporti diversi, con una copia esterna. Rimane una buona base, ma non esaurisce il tema. Occorre verificare che le copie siano effettivamente leggibili, protette da accessi non autorizzati e coerenti con le esigenze di ripristino dell’azienda.

Le copie immutabili, che non possono essere modificate o cancellate per un periodo definito, sono particolarmente utili contro ransomware ed errori amministrativi. Tuttavia non sostituiscono la protezione degli endpoint, la segmentazione della rete, l’autenticazione a più fattori e la formazione del personale. Un attacco può compromettere anche credenziali, configurazioni e servizi cloud: il disaster recovery deve considerare l’intero ecosistema, non solo i file.

Il cloud può ridurre alcune criticità, soprattutto se applicazioni, posta e documenti sono ospitati su piattaforme con alta disponibilità. Ma disponibilità del provider e recuperabilità dei dati aziendali non sono la stessa cosa. Bisogna stabilire quali dati vengono esportati o sottoposti a backup aggiuntivo, chi detiene le credenziali amministrative e cosa accade se un account viene compromesso o una configurazione viene modificata per errore.

Per le imprese con server locali, una soluzione ibrida è spesso un equilibrio concreto: backup locale per recuperi rapidi e copia esterna protetta per incidenti fisici gravi, come furto, incendio o allagamento. La scelta dipende da volumi, connessioni, applicazioni utilizzate e tempi concordati di rientro. L’obiettivo non è accumulare tecnologie, ma garantire che ogni componente critico abbia un’alternativa praticabile.

Testare il piano prima che serva davvero

Un piano mai testato è un’ipotesi, non una garanzia. Il test consente di misurare tempi effettivi, individuare istruzioni mancanti e verificare che backup, credenziali e risorse siano disponibili. Può iniziare con una simulazione ragionata e proseguire con il recupero controllato di file, macchine virtuali o applicazioni in un ambiente separato.

La frequenza dipende dalla velocità con cui cambiano sistemi e processi. Se l’azienda introduce un nuovo gestionale, modifica la rete, apre una sede, adotta Microsoft 365 o cambia il fornitore di connettività, il piano va aggiornato. Anche la crescita dell’organico e l’introduzione del lavoro da remoto modificano i punti da proteggere.

Durante ogni test è utile registrare quanto tempo è stato necessario, quali ostacoli sono emersi e quali correzioni servono. Non bisogna cercare una prova perfetta: lo scopo è trovare le debolezze in una condizione controllata, quando un ritardo non produce perdite economiche né pressione sui collaboratori.

Affidare il piano a un presidio IT continuativo

Per molte PMI, pianificare e mantenere il disaster recovery richiede competenze che non è efficiente internalizzare completamente. Il punto non è delegare ogni decisione, ma avere un interlocutore che conosca infrastruttura, sicurezza, fornitori e priorità operative dell’azienda. In questo modo, al verificarsi di un incidente, non si parte dalla ricerca di un tecnico disponibile: si attiva una procedura già conosciuta.

Un partner IT può coordinare backup, server, cloud, cybersecurity, posta, centralini e assistenza, documentando le dipendenze e verificando periodicamente lo stato delle protezioni. Per imprese di Milano, della Lombardia e del resto d’Italia, dove tempi di risposta e continuità del servizio incidono direttamente sulla competitività, questo presidio riduce l’incertezza operativa e semplifica il rapporto con più tecnologie.

La domanda giusta non è se si verificherà un problema, ma quanto l’azienda sarà pronta quando accadrà. Un piano di disaster recovery ben costruito trasforma un evento critico in una sequenza di azioni controllate, proteggendo dati, persone, clienti e capacità di continuare a lavorare.