RTO / RPO Recovery Time Objective e Recovery Point Objective.

Due orologi che misurano cose diverse

L'RTO e l'RPO sono i due obiettivi di ripristino che trasformano una vaga promessa di resilienza in numeri verificabili. È facile confonderli perché entrambi si esprimono in unità di tempo, ma misurano cose diverse e indicano soluzioni diverse. Il recovery time objective riguarda per quanto tempo puoi rimanere fermo. Il recovery point objective riguarda quanti dati puoi permetterti di perdere. Confondili e acquisterai l'architettura di ripristino sbagliata.

Immagina l'interruzione come un singolo istante su una linea temporale. L'RTO guarda in avanti da quell'istante: è la finestra massima tra il disservizio e il momento in cui il processo torna utilizzabile, prima che il danno diventi inaccettabile. L'RPO guarda indietro da quell'istante: è l'età massima dell'ultima copia valida dei dati a cui puoi ripristinare, che equivale ai dati più recenti che sei disposto a perdere. Un RTO di quattro ore con un RPO di quindici minuti significa che il servizio deve tornare attivo entro quattro ore e non può perdere più di quindici minuti di transazioni.

Da dove vengono i numeri e perché conta la responsabilità

Entrambi gli obiettivi sono risultati dell'analisi di impatto sul business, non ipotesi formulate nella sala server. La BIA studia ogni attività critica, misura come il danno di un disservizio cresce nel tempo e produce obiettivi di ripristino che il responsabile del processo convalida. Quella responsabilità è esattamente il punto. Un RTO e un RPO che un team tecnico fissa in modo isolato descrivono ciò che l'infrastruttura può fare, non ciò di cui il business ha bisogno, e il divario tra i due emerge solo durante un incidente reale, che è il momento peggiore per scoprirlo.

Gli obiettivi devono anche essere conciliati con il costo. Spingere un RPO verso zero significa replica continua o sincrona. Spingere un RTO verso pochi minuti significa capacità di standby a caldo che resta inattiva. Entrambi sono costosi, quindi la BIA impone una conversazione onesta su quali processi giustificano davvero quella spesa e quali possono tollerare una finestra più lunga. Stratificare le attività per livelli è normale: il motore dei pagamenti e il sito di marketing raramente meritano gli stessi obiettivi.

Come l'RTO e l'RPO si inseriscono negli standard

Questi obiettivi sono vocabolario fondamentale nei framework di continuità e resilienza. ISO 22301, lo standard internazionale per i sistemi di gestione della continuità operativa, tratta i recovery time e recovery point objectives come risultati dell'analisi di impatto che guidano la strategia e le soluzioni di continuità. Confluiscono direttamente nella progettazione del disaster recovery, nei piani di backup e nella scelta dei siti di ripristino. Nei settori regolamentati sono sempre più esaminati anziché dati per scontati: il regolamento europeo DORA fissa aspettative di continuità e di test per le entità finanziarie, e la Direttiva NIS 2 richiede misure di continuità operativa e di backup alle entità essenziali e importanti.

I professionisti fanno tre cose con questi numeri. Li derivano dalla BIA insieme ai responsabili del business. Progettano backup, replica e failover affinché l'architettura possa effettivamente rispettarli. Poi lo dimostrano con i test, perché un RTO non testato è un'aspirazione. L'obiettivo guadagna fiducia solo dopo che un'esercitazione di ripristino ha mostrato che il team può raggiungerlo in condizioni realistiche.