Nel mio lavoro quotidiano di gestione di infrastrutture enterprise, c’è una frase che sento ripetere in quasi ogni tavolo tecnico dopo un incidente: “Ma nel contratto c’era scritto RTO 4 ore”. Il problema è che quel numero, sulla carta, non ha mai coinciso con la realtà del ripristino. Ed è proprio qui che si gioca la differenza tra chi ha davvero un piano di continuità e chi ha solo un documento firmato.
Il gap tra il numero sul contratto e il cronometro reale
Il caso più emblematico che ho gestito riguardava un cliente con un RTO dichiarato di 4 ore su un gestionale critico e relativo database. In SLA, tutto perfetto. Nella realtà, dopo un guasto allo storage primario, il ripristino completo ha richiesto oltre 22 ore. Un gap di quasi sei volte il valore promesso.
Le cause, come quasi sempre, non erano una sola:
- Restore da backup lento: il backup esisteva, ma il ripristino avveniva da un repository deduplicato su disco lento, con un throughput reale che nessuno aveva mai misurato. Rehydration dei dati compresi, il tempo effettivo era triplo rispetto alle stime a tavolino.
- Dipendenze non mappate: il gestionale non ripartiva senza il servizio di autenticazione, un DNS interno e un file server condiviso. Nessuno di questi era nel “perimetro critico” del piano DR. Ripristinare l’applicativo senza le sue dipendenze significava avere una VM accesa ma un servizio inutilizzabile.
- Mancanza di test: il piano non era mai stato provato end-to-end. Il primo vero test di restore coincideva con il disastro reale. Il peggior momento possibile per scoprire che una procedura non funziona.
Il cliente aveva confuso, come capita spesso, il dato dichiarato con il reale ripristino. Aveva comprato un numero, non una capacità operativa.
Il trade-off che negozio più spesso: RPO contro costo
Quando progetto la protezione dati, il tavolo di negoziazione ruota quasi sempre intorno all’RPO, perché è lì che si misura direttamente il costo dell’infrastruttura. La domanda vera non è “quanti dati vuoi perdere?” — a cui tutti rispondono “zero” — ma “quanto sei disposto a spendere per avvicinarti allo zero?”.
Il dilemma ricorrente è tra replica sincrona e asincrona. Su ambienti VMware o Proxmox con storage replicato, la replica sincrona garantisce un RPO prossimo allo zero, ma impone:
- Latenza tra i siti sotto i 5 ms, quindi datacenter geograficamente vicini (spesso metropolitani), il che riduce la protezione contro disastri su area vasta.
- Banda dedicata e costosa, perché ogni scrittura deve essere confermata da entrambi i lati.
- Un impatto sulle performance applicative che non tutti i workload tollerano.
La replica asincrona, con snapshot ogni 15 minuti o ogni ora, abbatte i costi e consente distanze geografiche reali, a fronte di un RPO che va dai minuti alle decine di minuti. Dove metto io la linea che consiglio davvero? Segmentazione per tier applicativo:
- Tier 0 (transazionale, dati non ricostruibili): replica sincrona o asincrona a bassissima frequenza, RPO in minuti. Qui il costo si giustifica.
- Tier 1 (business critical): asincrona con snapshot ogni 15-60 minuti su banda geografica dimensionata sul delta reale, non su quello ipotizzato.
- Tier 2/3: backup giornaliero con RPO 24h. Proteggere tutto allo stesso livello è lo spreco più comune che vedo in gara.
La regola d’oro: l’RPO non lo decide il commerciale, lo decide chi conosce il valore economico del singolo dato perso.
L’errore ricorrente e l’unica verifica che impongo sempre
L’errore più frequente nei clienti, in fase di gara o di setup, è trattare RTO e RPO come sinonimi o come un unico numero. Vedo capitolati con “ripristino garantito in 2 ore” senza distinguere tra il tempo di rimessa in servizio (RTO) e la quantità di dati recuperabili (RPO). Sono due grandezze indipendenti: puoi ripartire in fretta perdendo un giorno di dati, o recuperare tutto ma impiegando un giorno. Confonderle significa non aver capito cosa si sta comprando.
La singola verifica che impongo sempre, senza eccezioni, è il test di restore reale e cronometrato. Non la lettura del log del backup che dice “completed”, ma il ripristino effettivo su ambiente isolato, con tanto di:
- Cronometro dal guasto simulato al servizio realmente utilizzabile, non solo alla VM accesa.
- Verifica delle dipendenze: l’applicativo risponde, l’utente si autentica, la transazione va a buon fine.
- Misura del throughput reale di restore, per capire se l’RTO regge quando i dati crescono.
Un backup che non è mai stato ripristinato non è un backup: è una scommessa. E il test va ripetuto periodicamente, perché le infrastrutture cambiano e un piano valido a gennaio può essere carta straccia a settembre.
Il verdetto
Conviene muoversi, ora. Il gap tra i numeri dichiarati e il ripristino reale non è un rischio teorico: è la norma per chi non ha mai testato. Investire in una mappatura seria delle dipendenze, in una segmentazione per tier dell’RPO e — soprattutto — in test di restore cronometrati e ripetuti costa una frazione di quanto costa scoprire il gap durante un disastro reale. Aspettare significa solo spostare la scoperta al momento peggiore. Verdetto: 1, muoversi subito.