Disaster recovery di rete: piano in 5 punti
Un disastro di rete non è una questione di se, ma di quando: guasto hardware, attacco ransomware, errore umano, allagamento data center o blackout prolungato. Avere un Disaster Recovery Plan (DRP) di rete strutturato significa ridurre il downtime da giorni a ore, e i danni economici da centinaia di migliaia di euro a frazioni minime. Vediamo i 5 punti fondamentali.
Punto 1: Analisi del rischio (BIA)
La Business Impact Analysis identifica quali servizi di rete sono critici e quanto downtime sono tollerabili. Per ogni servizio definisci due metriche: RTO (Recovery Time Objective) il tempo massimo accettabile di down (es. 4 ore per email, 1 ora per produzione); RPO (Recovery Point Objective) la perdita massima di dati accettabile (es. 24 ore per file, 5 minuti per database transazionale). Questi numeri guidano tutto il resto.
Punto 2: Backup configurazioni e dati
Backup di rete non è solo dati: serve backup di tutte le configurazioni firewall, switch, router, controller WiFi, server DNS/DHCP, certificati e chiavi. Implementa: backup automatico giornaliero delle config su git esterno; backup mensile offline su supporto removibile (regola 3-2-1: 3 copie, 2 supporti, 1 offsite); test di restore trimestrale per verificare integrità.
Punto 3: Ridondanza hardware
Identifica i Single Point of Failure (SPOF): un solo firewall, un solo switch core, una sola connessione internet, un solo DHCP server, un solo DC. Per ognuno valuta il costo della ridondanza vs costo del downtime. In genere: firewall HA cluster, switch core stack/MLAG, doppia uscita internet di operatori diversi, due DC, due DHCP, due DNS.
Punto 4: Site recovery
Se la sede primaria diventa inagibile (incendio, allagamento), serve una procedura per ripristinare la rete altrove. Opzioni: cold site sede vuota con hardware da spedire (RTO giorni); warm site hardware preinstallato ma config da ripristinare (RTO ore); hot site sito già attivo con replicazione in tempo reale (RTO minuti). Per la maggior parte delle PMI, un warm site con configurazioni nel git e VM in cloud è il compromesso migliore.
Punto 5: Test e drill
Un piano non testato non funziona. Pianifica drill periodici: tabletop exercise trimestrali (simulazione su carta), partial drill semestrale (restore di un servizio), full DR drill annuale (switch completo al sito secondario per ore). Documenta cosa ha funzionato e cosa no, aggiorna il piano.
Procedura passo-passo
- Esegui BIA con stakeholder business, non solo IT.
- Definisci RTO/RPO per ogni servizio in una matrice condivisa.
- Implementa backup automatico configurazioni (Oxidized + git remoto).
- Identifica e elimina SPOF principali entro 12 mesi.
- Definisci e documenta procedure DR per ogni scenario.
- Tieni hardware spare (1+1 per device critici).
- Predisponi vault offline con: credenziali, certificati, license key, contatti vendor.
- Pianifica drill annuale con report finale.
- Aggiorna il piano dopo ogni cambiamento significativo.
Errori comuni e come risolverli
- RTO irrealistici: RTO 15 minuti senza HA è impossibile. Allinea aspettative business e tecniche.
- Backup non testati: scopri al disastro che sono corrotti. Test mensile minimo.
- Documentazione del DR sul server primario: inutilizzabile durante il disastro. Copia offline.
- DR plan solo IT: serve coordinamento con HR, comunicazione, business continuity.
- Senza tabletop: nessuno conosce il piano fino al disastro reale.
Approfondimenti tecnici e scenari avanzati
Nella pratica quotidiana di un sysadmin che lavora con disaster recovery di rete, alcuni aspetti aggiuntivi meritano attenzione particolare. La gestione corretta in ambienti enterprise richiede di considerare l'integrazione con altri sistemi già presenti, la scalabilità futura e gli aspetti operativi day-2 spesso sottovalutati nella fase di design iniziale. Una configurazione che funziona bene per 50 utenti puo creare problemi seri a 200, ed e fondamentale prevedere fin da subito i punti di crescita.
Sul piano della sicurezza, l'attenzione si e spostata negli ultimi anni dal perimetro tradizionale al modello zero trust, dove ogni accesso viene verificato indipendentemente dalla provenienza. Per disaster recovery di rete questo significa applicare principi come minimum privilege, segregation of duties e continuous verification anche dove storicamente si dava fiducia implicita. Audit log, monitoring di anomalie e alert tempestivi sono ormai requisiti di base, non optional. Le normative europee come NIS2 e DORA stanno rendendo questi requisiti vincolanti per categorie sempre più ampie di aziende italiane.
Dal punto di vista operativo, l'automazione e ormai necessaria per gestire infrastrutture moderne con risorse umane limitate. Tool come Ansible, Terraform e script Python permettono di trattare la configurazione di rete come codice, versionata in git con pull request, review e CI/CD. Anche in piccole PMI vale la pena investire in queste pratiche: il tempo recuperato in change ripetitivi compensa rapidamente la curva di apprendimento iniziale, e la qualità aumenta perché le configurazioni sono validate prima del deployment.
Infine, il rapporto con i fornitori e gli operatori di telecomunicazione e importante. Avere chiari i punti di contatto NOC, le procedure di apertura ticket, gli SLA contrattuali e i meccanismi di escalation evita di scoprire questi dettagli durante un'incident critico. Documentare contratti, scadenze, modalita di rinnovo e clausole di uscita in un repository accessibile al team riduce la dipendenza da singole persone e migliora la continuita operativa nel medio periodo.
Domande frequenti
D: Quanto costa un DR plan?
R: Da 5000 euro per consulenza minima a 100.000+ per implementazione completa.
D: GDPR richiede DR plan?
R: Sì, art. 32 richiede capacità di ripristino tempestivo.
D: Cloud aiuta?
R: Sì, sposta parte del rischio al provider, ma serve comunque DR plan.
Hai bisogno di aiuto?
Se vuoi affidare la gestione rete aziendale al team di G Tech Group, scrivici tramite il modulo di contatto.