Quasi tutte le aziende sanno di avere bisogno di un piano di disaster recovery. Molte ne hanno uno scritto. Pochissime hanno un piano che funzionerebbe davvero in caso di incidente serio. Vediamo i cinque errori più comuni che trasformano i DR plan in carta straccia.
Errore 1: confondere backup e disaster recovery
Il backup è "ho una copia dei dati". Il disaster recovery è "in caso di disastro torno operativo entro X ore". Sono cose diverse. Avere i backup non significa avere DR: serve avere anche server di destinazione, configurazioni replicate, procedure di ripristino testate, infrastruttura di rete alternativa.
Errore 2: piano scritto ma mai testato
Un piano di DR non testato è una speranza, non una garanzia. Va simulato almeno una volta l'anno con un esercizio reale: in un weekend, si finge che il server principale sia distrutto e si ripristina tutto su infrastruttura alternativa. I primi test scoprono sempre problemi: password dimenticate, driver mancanti, configurazioni di rete non documentate, dipendenze tra sistemi non considerate. Ed è meglio scoprirli durante un test che durante un'emergenza vera.
Errore 3: RTO e RPO non definiti realisticamente
RTO (Recovery Time Objective) è quanto tempo posso restare giù. RPO (Recovery Point Objective) è quanti dati posso permettermi di perdere. Sono i due numeri chiave del DR.
- RTO non realistico: dichiarare "torniamo su in 2 ore" e poi avere un'architettura che richiede minimo 8 ore non è un piano, è un autoinganno.
- RPO troppo lungo: backup notturno significa che in caso di disastro alle 17 perdi un'intera giornata di lavoro. Per molte aziende è inaccettabile.
RTO e RPO vanno definiti con il management, non con l'IT, perché sono decisioni di business.
Errore 4: dipendenze nascoste
Quando un sistema cade, ne porta giù altri tramite dipendenze che nessuno ha mappato:
- Il gestionale dipende dal database, ma anche dall'Active Directory per l'autenticazione.
- Il sito web dipende dal DNS, dai certificati SSL, dal database.
- Il telefono VoIP dipende dalla connettività e dalla configurazione del firewall.
Una mappa delle dipendenze è essenziale. Senza, il ripristino procede a tentoni.
Errore 5: chi fa cosa in emergenza
Il DR plan non è solo tecnico. Deve definire:
- Chi prende le decisioni se il responsabile IT non è raggiungibile.
- Chi comunica con i clienti, dipendenti, fornitori.
- Chi notifica il Garante se ci sono dati personali coinvolti.
- Quali decisioni si possono prendere senza riferirsi alla direzione.
- Come si attivano i fornitori esterni nel weekend.
Senza questa parte, il DR diventa caos organizzativo anche se la parte tecnica funziona.
Un DR plan minimo per PMI
Non serve un documento di 200 pagine. Per una PMI tipica bastano:
- Lista sistemi critici e dipendenze.
- RTO e RPO per ciascuno.
- Procedura di ripristino step-by-step (anche stampata, in un cassetto).
- Lista contatti emergenza (con backup secondari).
- Calendario test (almeno annuale).
Conclusione
Un DR plan efficace è un investimento minimo che salva l'azienda nei momenti peggiori. Possiamo aiutarti a costruirlo in modo realistico, basato sulle tue effettive esigenze, e a testarlo periodicamente.