1. Scambiare il backup per un piano di Disaster Recovery
È l’equivoco più diffuso. Avere copie di backup dei dati è necessario, ma non sufficiente: il backup risponde alla domanda «ho ancora i dati?», mentre il Disaster Recovery risponde a «in quanto tempo torno operativo?». Sono due piani distinti, con obiettivi e meccanismi diversi.
Un archivio di backup ben fatto può comunque richiedere ore o giorni per essere reso utilizzabile: occorre ricostruire i server, riconfigurare reti e applicazioni, ripristinare i dati nell’ordine corretto. Una vera strategia di Disaster Recovery prevede invece infrastrutture e procedure pensate per rimettere in piedi i servizi entro tempi definiti, non solo per conservare i file. Considerare i due ambiti come sinonimi è il primo passo verso una brutta sorpresa.
2. Non definire RTO e RPO
Senza obiettivi misurabili, un piano di ripristino resta una dichiarazione di intenti. I due parametri di riferimento sono l’RTO (Recovery Time Objective), cioè il tempo massimo accettabile per tornare operativi, e l’RPO (Recovery Point Objective), cioè la quantità massima di dati che ci si può permettere di perdere, misurata come distanza dall’ultimo punto di ripristino valido.
Definire RTO e RPO non è un esercizio teorico: sono i numeri che guidano ogni scelta tecnica ed economica. Un servizio critico che non può fermarsi richiederà soluzioni di replica continua, mentre un sistema secondario può tollerare finestre più ampie e costi inferiori. Stabilire questi valori, condividerli con il management e tradurli in requisiti concreti è ciò che trasforma un buon proposito in un piano governabile.
3. Non testare mai il ripristino
Un piano di Disaster Recovery che non viene mai messo alla prova è, di fatto, un’ipotesi. È sorprendentemente frequente scoprire che le procedure documentate non funzionano come previsto solo nel momento dell’emergenza: backup illeggibili, dipendenze non considerate, credenziali scadute, passaggi che richiedono persone non più in azienda.
Il test di ripristino va pianificato con regolarità e, idealmente, simulando scenari realistici. Provare davvero a ripristinare un sistema in un ambiente isolato permette di misurare i tempi effettivi, validare l’integrità dei dati e correggere le procedure prima che servano sul serio. Un piano testato periodicamente è l’unico di cui ci si possa fidare.
4. Concentrare tutto in un’unica sede
Se dati, sistemi e copie di sicurezza risiedono nello stesso luogo, quel luogo diventa un single point of failure. Un incendio, un allagamento, un’interruzione prolungata di energia o un guasto infrastrutturale possono mettere fuori uso contemporaneamente produzione e ripristino, vanificando l’intera strategia.
Il principio della regola 3-2-1 — più copie dei dati, su supporti diversi, con almeno una conservata fuori sede — nasce proprio per spezzare questa dipendenza. La distribuzione geografica, su data center separati e indipendenti, riduce drasticamente il rischio che un singolo evento comprometta tutto. La ridondanza ha un costo, ma è esattamente il costo che si paga per non avere un unico punto in cui tutto può rompersi.
5. Trascurare persone, runbook e processi
La tecnologia è solo una parte del Disaster Recovery. Nel momento critico contano la chiarezza dei ruoli, la disponibilità delle informazioni e la capacità di agire in fretta sotto pressione. Un piano che vive solo nella testa di una persona, o in un documento che nessuno aggiorna, è fragile per definizione.
Servono runbook operativi chiari, che descrivano passo dopo passo chi fa cosa, in quale ordine e con quali strumenti, comprese le procedure di escalation e i contatti aggiornati. Il personale va formato e coinvolto nelle prove, così da sapere come muoversi quando il tempo è poco e lo stress è alto. Persone, processi e documentazione trasformano un insieme di tecnologie in una vera capacità di reazione.
Da reazione a continuità
Evitare questi cinque errori significa passare da una logica difensiva, fatta di backup conservati e sperati, a una logica di continuità operativa: la capacità dichiarata e verificata di mantenere i servizi attivi, o di ripristinarli entro tempi noti, anche quando qualcosa va storto.
È un percorso che richiede competenze, infrastruttura distribuita e disciplina nel tempo. Sundata affianca PMI, Pubblica Amministrazione e imprese con servizi di DRaaS (Disaster Recovery as a Service) e soluzioni di Business Continuity, progettati su obiettivi di RTO e RPO concordati e ospitati su data center indipendenti. Se vuoi capire dove si trovano oggi i punti deboli della tua strategia di ripristino, è un buon punto di partenza per parlarne.