Disaster Recovery per PMI nel 2026: la guida pratica
Lettura 8 min · AstraLoop Studio
Il server che si blocca un venerdì pomeriggio, il NAS che smette di rispondere dopo un aggiornamento, il ransomware che cifra la cartella condivisa mentre l'ufficio amministrazione sta chiudendo le fatture del mese. Non sono scenari da film: sono le telefonate che arrivano quando il disaster recovery non c'è, o c'è solo sulla carta.
Molte PMI confondono il disaster recovery con il backup. È l'errore più comune, e anche il più pericoloso, perché fa credere di essere protetti quando in realtà non lo si è.
Backup e disaster recovery non sono la stessa cosa
Il backup è la copia dei dati. Il disaster recovery è il piano che dice cosa succede dopo: dove sono quei dati, chi li rimette in piedi, su quale hardware o servizio cloud, e in quanto tempo l'azienda torna operativa. Puoi avere un backup perfetto, fatto ogni notte, e non avere nessun disaster recovery: se il server fisico si guasta e nessuno sa dove riavviare il gestionale, quel backup resta un file inutile su un disco esterno chiuso in un cassetto.
Il disaster recovery risponde a una domanda diversa dal backup: non "ho salvato i dati?" ma "quanto tempo mi serve per tornare a lavorare, e con quanti dati persi nel frattempo?".
Tempo massimo di fermo e quantità di dati che puoi perdere
Due numeri, non uno, fanno la differenza tra un piano serio e uno improvvisato.
Il primo è il tempo massimo di fermo che l'azienda può reggere prima che il danno diventi serio: un'ora, mezza giornata, un giorno intero. Per un negozio con la cassa collegata al gestionale, un'ora di blocco vuol dire vendite perse e clienti che se ne vanno altrove. Per uno studio di progettazione che lavora su commesse con scadenze settimanali, mezza giornata di fermo può essere tollerabile senza conseguenze gravi.
Il secondo è quanti dati puoi permetterti di perdere se il disastro arriva a metà mattina: gli ordini inseriti nell'ultima ora, le presenze timbrate, i movimenti di magazzino. Se il backup gira una volta a notte, in caso di guasto pomeridiano perdi tutta la giornata di lavoro. Per un'azienda di produzione che scarica materiale da un ordine ogni pochi minuti, questo può voler dire rifare da capo la tracciabilità di un lotto.
Questi due parametri vanno decisi prima, a mente fredda, non durante l'emergenza. E vanno decisi guardando il proprio processo reale, non un valore standard preso da un contratto tipo.
L'esigenza cambia parecchio a seconda di chi sei
Non esiste un disaster recovery uguale per tutti, perché non esiste un'azienda uguale a un'altra.
Uno studio professionale con cinque postazioni e un server in ufficio ha un problema soprattutto sui documenti e sulla posta: la priorità è recuperare in fretta pratiche, fascicoli e scadenze, spesso con vincoli di conservazione documentale da rispettare. Un'officina o un'azienda di produzione con macchine collegate al gestionale ha un problema più fisico: se si ferma il tracciamento della produzione, si fermano anche le macchine, e il fermo si misura in pezzi non consegnati, non solo in ore di ufficio.
Un e-commerce o un negozio con più punti vendita ha un'esigenza quasi opposta: i volumi di transazioni sono alti e continui, quindi anche una perdita di dati di pochi minuti (ordini, pagamenti, giacenze) genera un lavoro di riconciliazione lungo e delicato. Un'azienda di servizi con pochi dipendenti e un solo ufficio, al contrario, può ragionevolmente accettare qualche ora di fermo in più, a patto di avere comunque un piano scritto e testato.
La dimensione conta, ma conta ancora di più il tipo di flusso: un'azienda che vende un servizio continuo (prenotazioni, appuntamenti, centralino) ha bisogno di continuità quasi immediata; un'azienda che produce a lotti o lavora su commessa può reggere un fermo più lungo purché sappia esattamente cosa fare.
La prova di ripristino: un piano mai testato non è un piano
Qui casca la maggior parte delle aziende che pensano di essere a posto. Hanno un contratto di backup, magari anche una copia in cloud, ma non hanno mai provato a ripristinare davvero un ambiente di lavoro da zero.
La prova di ripristino è l'unico modo per sapere se il piano funziona: si prende l'ultima copia disponibile, si prova a rimettere in piedi il gestionale su una macchina diversa (o su un ambiente cloud separato) e si misura quanto tempo serve davvero, non quanto tempo si pensava servisse. Spesso si scopre che mancano le licenze, che le credenziali sono cambiate, che qualche integrazione con un servizio esterno va riconfigurata a mano, che il file di backup più recente in realtà è corrotto da settimane e nessuno se n'era accorto.
Una prova di ripristino fatta una volta all'anno, o dopo ogni modifica importante all'infrastruttura, costa poco rispetto al rischio di scoprire tutto questo il giorno del disastro vero.
Sede secondaria o cloud: dove tenere la copia
La regola pratica, indipendentemente dal settore, è che la copia dei dati non deve stare nello stesso posto dei dati originali. Un backup salvato su un disco nello stesso armadio del server protegge da un guasto hardware, ma non da un incendio, un allagamento o un furto.
Le due strade concrete sono una sede secondaria (un'altra sede aziendale, o anche solo un ufficio diverso, dove replicare i dati) e un servizio in cloud, dove il fornitore garantisce ridondanza geografica senza che l'azienda debba gestire un secondo server fisico. Per una PMI senza un tecnico interno, il cloud tende a essere la scelta più sostenibile: elimina la necessità di manutenere hardware di riserva e permette di ripristinare da qualsiasi postazione connessa, non solo dall'ufficio principale.
Se non sai ancora quanto tempo di fermo puoi permetterti o dove finisce davvero la tua ultima copia dei dati, è il momento giusto per fare chiarezza insieme a chi progetta gestionali su misura anche per la continuità operativa.
Non è un dettaglio tecnico secondario: è la differenza tra riaprire in un giorno da un'altra postazione, o restare fermi finché non si trova un tecnico disponibile per intervenire fisicamente sul server guasto.
Chi fa cosa quando succede davvero
Il momento del disastro non è il momento per inventare un piano. Serve sapere, scritto da qualche parte e non solo nella testa del titolare, chi chiama il fornitore del gestionale, chi avvisa i clienti se il sito o il centralino sono coinvolti, chi decide se e quando passare a una modalità manuale temporanea (carta e penna per gli ordini, per esempio), e chi verifica che i dati ripristinati siano coerenti prima di far ripartire tutti.
In un'azienda piccola questo può essere anche solo una pagina: tre o quattro nomi, un numero di telefono del fornitore, la sequenza di passi in ordine. Non serve un documento da cinquanta pagine per essere efficace: serve che chi deve agire sappia cosa fare senza dover cercare informazioni mentre l'azienda è ferma.
Quanto costa un'ora di fermo
È la domanda che decide quanto ha senso investire in disaster recovery, ed è anche quella che quasi nessuno si fa prima del disastro. Il calcolo non è complicato: quanto fattura in media l'azienda in un'ora di attività, più il costo del personale comunque pagato mentre non può lavorare, più il danno meno visibile ma reale di clienti che in quell'ora non riescono a ordinare, prenotare o essere serviti.
Per un negozio o un ristorante, un'ora di fermo si traduce quasi subito in vendite mancate. Per uno studio professionale, il costo è più diluito ma si accumula: pratiche che slittano, scadenze da recuperare, clienti che aspettano una risposta. Confrontare questo numero, anche stimato per grandi linee, con il costo di un piano di disaster recovery adeguato è l'esercizio che rende la spesa comprensibile invece che astratta: spesso un canone mensile per postazione risulta molto più basso del costo reale di anche solo poche ore di fermo all'anno.
Modulo pronto o costruito sul processo: come si sceglie
Molti verticali di settore e molte soluzioni pronte all'uso includono già una funzione di backup, e a volte anche un piano di ripristino base. Per un'azienda con un processo semplice, un unico gestionale e volumi di dati contenuti, questo può bastare tranquillamente: non ha senso costruire qualcosa su misura se il modulo standard copre già tempo di fermo accettabile e perdita dati tollerabile per quel tipo di attività.
Il discorso cambia quando i dati critici sono sparsi su più sistemi che non parlano tra loro (un gestionale per la produzione, un altro per la contabilità, un centralino, un portale ordini), oppure quando il processo ha specificità che il prodotto pronto costringe a piegare: tempi di ripristino diversi per sistemi diversi, priorità di recupero specifiche (magazzino prima della fatturazione, per esempio), o integrazioni particolari che un modulo generico non gestisce. In questi casi un gestionale su misura permette di progettare il disaster recovery attorno al processo reale dell'azienda, invece di adattare il processo al piano previsto dal fornitore. Vale lo stesso ragionamento che si fa quando si sceglie tra un prodotto standard e una soluzione su misura per qualsiasi altra funzione aziendale: prima si verifica se lo standard basta, poi si valuta il su misura solo dove serve davvero.
Sul lato costi, per farsi un'idea di massima prima di parlarne con un fornitore, può essere utile partire da una stima di preventivo per capire l'ordine di grandezza di un progetto costruito sulle proprie esigenze, tenendo conto che l'investimento iniziale va sempre confrontato con il costo del fermo evitato, non guardato da solo.
Il disaster recovery non è un capitolo tecnico da delegare e dimenticare. È una decisione operativa, con numeri concreti: quanto puoi stare fermo, quanti dati puoi perdere, quanto ti costa ogni ora di blocco. Se in AstraLoop guardiamo il tuo processo insieme, possiamo dirti onestamente se ti basta rafforzare quello che hai già o se conviene progettare un piano su misura attorno a come lavori davvero.
Domande frequenti
Qual è la differenza tra backup e disaster recovery?
Il backup è la copia dei dati. Il disaster recovery è il piano completo che dice dove sono quei dati, chi li rimette in funzione, su quale infrastruttura e in quanto tempo l'azienda torna operativa. Puoi avere un backup perfetto e nessun disaster recovery: se nessuno sa come ripristinare il gestionale, quel backup resta inutile.
Quanto costa un piano di disaster recovery per una PMI?
Dipende da quanti sistemi devi proteggere e da quanto in fretta devi tornare operativo. In genere si parla di un canone mensile per postazione o per utente, più un eventuale investimento iniziale una tantum per la configurazione. Il modo corretto di valutarlo è confrontarlo con il costo reale di un'ora di fermo per la tua attività.
Ogni quanto va testata la prova di ripristino?
Almeno una volta all'anno, e comunque dopo ogni cambiamento importante all'infrastruttura o al gestionale. Un piano mai testato spesso nasconde problemi (licenze mancanti, credenziali scadute, backup corrotti) che emergono solo quando è troppo tardi.
Meglio una sede secondaria fisica o il cloud?
Per una PMI senza un tecnico interno, il cloud è quasi sempre la scelta più sostenibile: elimina la necessità di gestire un secondo server e permette di ripristinare da qualsiasi postazione connessa. Una sede secondaria fisica resta un'opzione valida solo se l'azienda ha già più sedi operative.
Il modulo di backup del mio gestionale standard basta per il disaster recovery?
Spesso sì, se hai un processo semplice, un unico gestionale e volumi di dati contenuti. Il su misura ha senso quando i dati critici sono sparsi su più sistemi che non comunicano tra loro, o quando servono priorità di ripristino specifiche che un modulo generico non gestisce.
Il disaster recovery non si improvvisa il giorno del guasto: si progetta prima, sul tuo processo reale. Raccontaci come lavori oggi e ti diciamo onestamente cosa ti serve davvero, scopri il nostro approccio al gestionale su misura.