Molte piccole e medie imprese pensano di essere al sicuro perché “facciamo il backup ogni notte”. È un’affermazione rassicurante, ma incompleta. Il backup è una condizione necessaria per la sicurezza dei dati aziendali, non sufficiente per garantire la continuità operativa. La differenza tra backup e disaster recovery è esattamente questa: il primo risponde alla domanda “ho una copia dei miei dati?”, il secondo risponde alla domanda, molto più urgente in caso di emergenza, “in quanto tempo torno operativo?”.
Capire questa distinzione non è un esercizio teorico. È la differenza tra un fermo di qualche ora e un fermo di diversi giorni, tra un incidente gestito e un danno che si trascina per settimane su fatturato, clienti e reputazione.
Cosa fa (e cosa non fa) un backup da solo
Un backup è una copia dei dati, salvata in un luogo diverso da quello originale, che permette di recuperare file, documenti, database o intere macchine virtuali in caso di perdita, guasto hardware, errore umano o evento accidentale come un incendio o un allagamento.
Fatto bene, un backup garantisce che i dati non vadano persi. Non garantisce però:
- Tempi di ripristino rapidi: ripristinare un server da un backup può richiedere ore, a volte giorni, soprattutto se mancano procedure chiare o hardware sostitutivo pronto all’uso.
- Continuità dei servizi durante il ripristino: mentre si ripristina, l’azienda resta ferma. Il backup dice che i dati ci sono, non dice come l’azienda continua a lavorare nel frattempo.
- Priorità tra i sistemi: un backup generico tratta allo stesso modo il server della posta elettronica e il gestionale che emette le fatture. In un’emergenza reale, invece, serve sapere cosa ripristinare per primo.
In altre parole, un backup risponde bene alla domanda “recupero i dati?”, ma lascia scoperta la domanda più critica per il business: “quanto tempo l’azienda resta ferma?”.
Cosa aggiunge un piano di disaster recovery
Il disaster recovery (DR) è un insieme di procedure, ruoli e tecnologie pensato per far ripartire i sistemi informatici — e quindi l’operatività aziendale — entro tempi definiti e concordati in anticipo. Un piano di DR serio stabilisce, prima che accada qualsiasi cosa:
- quali sistemi sono critici e vanno ripristinati per primi (es. gestionale, posta elettronica, centralino, e-commerce);
- in quanto tempo massimo ciascun sistema deve tornare operativo (il cosiddetto RTO, Recovery Time Objective);
- quanti dati ci si può permettere di perdere nel peggiore dei casi (il cosiddetto RPO, Recovery Point Objective);
- chi fa cosa durante l’emergenza, con ruoli e responsabilità già assegnati.
Il disaster recovery, quindi, non sostituisce il backup: lo mette a sistema dentro un processo con tempi e responsabilità definite, trasformando una semplice copia dei dati in una reale capacità di continuità operativa.
Un esempio pratico: stesso incidente, esito diverso con o senza DR
Immaginiamo il guasto hardware di un server che ospita il gestionale aziendale, un evento tutt’altro che raro.
Senza un piano di disaster recovery: l’IT interno (o il fornitore di turno) individua il problema, cerca l’ultimo backup disponibile, verifica che sia integro, procura hardware sostitutivo se necessario, reinstalla il sistema operativo, ripristina i dati, verifica che tutto funzioni. Senza una procedura scritta e testata in anticipo, questo percorso può richiedere da uno a diversi giorni lavorativi, con l’azienda ferma o costretta a lavorare “a mano” nel frattempo.
Con un piano di disaster recovery: il problema viene rilevato, si attiva una procedura già definita (che magari prevede un ambiente di ripristino pronto, anche in cloud), i ruoli di chi interviene sono già chiari, e il sistema torna operativo entro il tempo massimo (RTO) stabilito a monte — spesso poche ore, a volte meno. Il dato di partenza è lo stesso: un backup. Il risultato per l’azienda è completamente diverso.
Come StartIT copre entrambi gli aspetti
StartIT, il servizio StartApp per la gestione delle infrastrutture aziendali e della loro continuità, unisce questi due livelli in un’unica soluzione: da un lato la protezione e la copia dei dati aziendali, dall’altro procedure e strumenti pensati per ridurre concretamente i tempi di ripristino in caso di incidente. L’obiettivo non è solo “avere una copia da qualche parte”, ma costruire insieme al cliente un percorso di ripristino realistico, verificato e proporzionato alle esigenze della singola azienda, senza promettere soluzioni standard uguali per tutti.
Un aspetto importante da chiarire: la protezione da minacce informatiche come ransomware o malware, e più in generale la parte di sicurezza informatica in senso stretto, è oggi seguita da Defendia, l’altra suite del gruppo. StartApp lavora sul fronte della continuità operativa — mantenere l’azienda in funzione — mentre Defendia lavora sul fronte della protezione da attacchi e minacce. I due ambiti sono complementari e spesso si integrano, ma restano competenze distinte.
Conclusione: continuità operativa, non solo backup
Se la tua azienda ha oggi solo un backup, senza un piano di disaster recovery scritto e testato, probabilmente stai coprendo solo metà del problema. Vale la pena chiedersi: se domani un server si guastasse, sappiamo davvero quanto tempo servirebbe per tornare operativi, e chi farebbe cosa?
Con StartIT, StartApp affianca le PMI nella costruzione di un percorso di continuità operativa completo, dal backup dei dati fino al ripristino strutturato dei sistemi critici. Se vuoi capire a che punto è la tua azienda su questo fronte, contatta il team StartApp per una valutazione della tua attuale strategia di backup e disaster recovery.
Domande frequenti
Un backup in cloud è sufficiente come disaster recovery?
No, non da solo. Un backup in cloud è un ottimo punto di partenza perché mette i dati al sicuro in una posizione geograficamente separata da quella originale, riducendo il rischio di perdita totale. Ma un vero piano di disaster recovery aggiunge elementi che il solo backup non copre: tempi di ripristino definiti (RTO), priorità tra i sistemi da recuperare, procedure operative e ruoli assegnati a chi deve intervenire. Senza questi elementi, anche un backup in cloud rischia di tradursi in un ripristino lento e non pianificato.
Ogni quanto va testato un piano di disaster recovery?
Un piano di disaster recovery che non viene mai testato è, di fatto, solo un documento teorico: non si può sapere se funziona davvero finché non lo si prova. Come regola generale, è buona pratica testare il piano almeno una volta all’anno, e comunque ogni volta che cambiano in modo significativo i sistemi informatici aziendali (nuovo gestionale, nuovo server, migrazione di un servizio in cloud). Il test può essere parziale (si verifica il ripristino di un singolo sistema critico) o completo (si simula uno scenario di emergenza reale), ma va sempre documentato per individuare eventuali punti deboli della procedura.