Il malinteso che costa il ripristino
Nel gergo enterprise italiano DR e BC vengono usati come sinonimi. Non lo sono. Il Disaster Recovery è la capacità tecnica di ripristinare sistemi e dati dopo un incidente: repliche, backup offsite, RTO e RPO scritti in un documento. La Business Continuity è un’altra cosa: è la capacità dell’organizzazione di continuare a erogare il servizio mentre l’incidente è in corso. Il primo è un progetto tecnico, la seconda è un modello operativo. Confonderli significa credere di essere protetti perché “abbiamo il DR”, salvo scoprire nel momento sbagliato che nessuno sa da dove ripartire.
Il DR che c’è sulla carta ma non nella realtà
La mia esperienza sul campo mi ha portato a una convinzione precisa: quasi nessun DR plan tiene conto del reale utilizzo delle applicazioni. Il documento viene scritto una volta, validato in fase di collaudo, e poi congelato. Nel frattempo l’infrastruttura vive: ogni giorno nascono nuove dipendenze, nuovi microservizi, nuove integrazioni tra applicativi, nuovi flussi verso servizi esterni. Il piano invecchia da solo, silenziosamente.
Il risultato è il classico paradosso: sulla carta ci sono repliche perfette, backup offsite verificati, RTO/RPO firmati dal management. Ma quando arriva l’incidente vero, quello che manca non è il dato — è il contesto:
- Runbook obsoleti o inesistenti: chi fa cosa, in quale ordine, con quali credenziali. Spesso la conoscenza è nella testa di una sola persona.
- DNS e failover manuali: i dati sono nel sito secondario, ma il record che punta i client non viene aggiornato in automatico, e nessuno ricorda dove si cambia.
- Dipendenze applicative non mappate: l’applicazione A riparte, ma dipende da un servizio B che nel DR plan non compariva perché è stato introdotto sei mesi dopo.
- Persone non reperibili: il piano presuppone che alle 3 di notte ci sia qualcuno con i permessi giusti. Non è così.
Il DR non “salta” per un problema di storage. Salta perché la Business Continuity non è mai stata progettata come processo vivo.
Perché preferisco la Business Continuity al DR classico
Per questo motivo, quando posso influenzare l’architettura, spingo verso modelli in cui i due siti sono sempre operativi. Non un sito primario e uno “dormiente” da risvegliare in emergenza, ma due datacenter attivi che erogano servizio in parallelo. In questo scenario non esiste il momento traumatico del “andiamo in DR”: se un sito cade, l’altro sta già lavorando. La continuità è la condizione normale, non l’eccezione da orchestrare sotto stress.
Il vantaggio operativo è enorme: testi la resilienza ogni giorno, non una volta l’anno. Le dipendenze applicative sono già validate perché il traffico gira su entrambi i lati. Il DNS e il bilanciamento sono parte del funzionamento ordinario, non una procedura d’emergenza da improvvisare.
Il trade-off che imponi a chi vuole “RPO zero su tutto”
Qui arriva la conversazione difficile con il cliente. Chi chiede RPO zero su tutto quasi sempre non ha idea del costo. RPO zero significa replica sincrona, che significa latenza sotto controllo tra i siti, link dedicati, e — nel mondo virtualizzazione — architetture tipo stretched cluster con storage in mirror sincrono. Su Proxmox o VMware questo si traduce in doppio storage performante, rete a bassa latenza garantita e complessità operativa che cresce in modo non lineare.
Il modo in cui lo spiego è semplice e brutale: non tutte le applicazioni valgono lo stesso RPO. Si costruisce insieme una classificazione:
- Tier 1 — sistemi che generano fatturato o bloccano l’azienda: replica sincrona, RPO ~zero. Costa, ma è giustificato.
- Tier 2 — importanti ma tollerano minuti di perdita: replica asincrona, RTO di ore.
- Tier 3 — tutto il resto: backup + restore, RPO di ore, RTO negoziabile.
Il messaggio al budget è: “RPO zero su tutto raddoppia l’infrastruttura per proteggere anche ciò che nessuno noterebbe se sparisse per un’ora”. Nove volte su dieci, davanti al numero, il cliente ridimensiona la richiesta da solo.
Cosa testare per primo: il consiglio al CISO
Il tabletop non basta. Il DR test reale è quello dove si rompe ciò che nessuno aveva previsto, e i punti dolenti sono sempre gli stessi. Al CISO oggi consiglio di testare in questo ordine:
- Autenticazione e Active Directory: se l’AD non è raggiungibile o non riparte per primo, non ti logghi da nessuna parte. È il single point of failure più sottovalutato.
- Ordine di boot delle VM: le dipendenze contano. Database prima degli applicativi, servizi di rete prima di tutto.
- Licenze: molti software si legano al MAC address o al server originale e rifiutano di partire nel sito secondario.
- Tempi di re-hydration: quanto ci mette davvero un ambiente a tornare consistente e usabile, non solo acceso.
Verdetto: muoversi (1)
Il verdetto è 1: conviene muoversi ora. Non per comprare l’ennesima tecnologia di replica, ma per trasformare il DR da documento congelato a processo vivo. Chi ha un piano non aggiornato ha un falso senso di sicurezza, che è peggio di non averlo. La strada è progettare per la Business Continuity — due siti attivi dove possibile — classificare gli RPO in base al valore reale delle applicazioni, e testare per davvero partendo da AD e autenticazione. Aspettare significa scoprire il buco nel momento peggiore. Muoversi significa scoprirlo durante un test, quando ancora puoi permetterti di sbagliare.