RTO e RPO nel disaster recovery: definizioni, esempi e come fissarli

L'RTO (recovery time objective) è il tempo massimo per cui un sistema può restare fermo dopo un'interruzione. L'RPO (recovery point objective) è la quantità massima di dati che potete permettervi di perdere, misurata come tempo trascorso dall'ultima copia utilizzabile. Un RTO di 4 ore e un RPO di 15 minuti significano: tornare online entro 4 ore, perdendo al massimo 15 minuti di dati.

Punti chiave

• L'RTO guarda avanti dall'interruzione (quanto passa prima che il servizio torni). L'RPO guarda indietro (quanto è vecchia l'ultima copia valida dei dati).
• Entrambi sono decisioni di business. Fissateli per ogni sistema con una business impact analysis, poi scegliete la tecnologia che li rispetta.
• La frequenza dei backup pone un limite all'RPO: con backup ogni 4 ore, la perdita di dati nel caso peggiore è di circa 4 ore.
• Obiettivi più stringenti costano di più. RTO/RPO quasi nulli richiedono replica e capacità di standby in una seconda sede.
• Gli obiettivi sulla carta valgono poco finché un test non ha misurato il tempo di ripristino e la perdita di dati reali.

Cos'è l'RTO nel disaster recovery?

L'RTO è il tempo massimo accettabile tra l'interruzione di un servizio e il suo ripristino. AWS lo definisce "il ritardo massimo accettabile tra l'interruzione del servizio e il ripristino del servizio" nel whitepaper Disaster Recovery of Workloads on AWS. Il NIST lo inquadra dal lato business: il tempo in cui un sistema può essere in ripristino "prima di avere un impatto negativo sulla missione dell'organizzazione o sui processi di missione/business".

L'RTO copre l'intero ripristino, non solo il restore tecnico. Rilevamento, decisione di attivare il piano di DR, ripristino dei dati, validazione dell'applicazione e passaggio degli utenti contano tutti. I team che cronometrano solo il restore di solito mancano l'RTO in un evento reale.

Cos'è l'RPO nel disaster recovery?

L'RPO è la perdita massima accettabile di dati, espressa in tempo. AWS lo definisce "il tempo massimo accettabile trascorso dall'ultimo punto di ripristino dei dati". Se il vostro RPO è di 1 ora, dopo un guasto dovete poter ripristinare dati vecchi al massimo di 1 ora.

L'RPO dipende da quanto spesso copiate i dati. Backup notturni danno un RPO nel caso peggiore di circa 24 ore. Backup dei log del database ogni 15 minuti ne danno circa 15. La replica continua può avvicinarlo a zero, con un'avvertenza trattata più avanti: la replica copia anche corruzioni e cancellazioni.

RTO e RPO: la differenza a colpo d'occhio

Esempi svolti

Esempio 1: un sistema di ordini. Un negozio online fissa un RTO di 4 ore e un RPO di 15 minuti. Il database si guasta alle 10:00. Il negozio deve tornare a ricevere ordini entro le 14:00 e al massimo possono mancare gli ordini effettuati tra le 09:45 e le 10:00. I backup notturni non bastano; servono backup dei log delle transazioni o una replica almeno ogni 15 minuti, più un modo scriptato per ricostruire il livello applicativo entro 4 ore.

Esempio 2: verificare una pianificazione dei backup. Un sistema finanziario ha un backup ogni 6 ore e un restore completo richiede 3 ore. Se il business chiede un RPO di 1 ora e un RTO di 2 ore, entrambi gli obiettivi falliscono: la perdita di dati nel caso peggiore è di circa 6 ore e il solo restore supera l'RTO. La soluzione è o backup più frequenti con un metodo di ripristino più veloce, oppure una decisione di business di accettare obiettivi meno stringenti.

Esempio 3: suddividere il portafoglio in livelli. La maggior parte delle aziende raggruppa i sistemi in livelli invece di fissare gli obiettivi uno per uno. Le cifre qui sotto sono indicative, non uno standard.

La colonna della strategia segue i quattro approcci del whitepaper AWS, dove backup e restore garantisce un ripristino in ore e il multi-sito active/active in tempo quasi reale. La nostra guida al piano di disaster recovery spiega ogni strategia e come scegliere.

Che rapporto c'è tra RTO, RPO e maximum tolerable downtime?

Il maximum tolerable downtime (MTD) è il tempo per cui un processo aziendale può essere interrotto prima che il danno diventi grave. La NIST SP 800-34 spiega che l'RTO "deve normalmente essere più breve dell'MTD", perché una volta tornati i sistemi, il personale ha ancora bisogno di tempo per smaltire gli arretrati e reinserire i dati persi. L'RPO non fa parte dell'MTD: descrive quanti dati il processo può permettersi di perdere (NIST SP 800-34 Rev. 1).

In pratica: se il processo degli ordini può sopravvivere 8 ore senza sistemi e lo smaltimento richiede 2 ore, l'RTO IT deve essere di 6 ore o meno.

Come fissare RTO e RPO

1. Elencate i processi aziendali e le loro dipendenze. Associate ogni processo alle applicazioni, ai database, ai servizi di identità e alle terze parti di cui ha bisogno.
2. Stimate l'impatto di fermo e perdita di dati nel tempo. Ricavi, penali contrattuali, esposizione normativa, sicurezza e reputazione. AWS sottolinea che l'impatto può dipendere dal momento: un'interruzione delle paghe subito prima del giorno di pagamento pesa molto più di una subito dopo.
3. Proponete obiettivi per livello e fateli approvare dal responsabile di business. L'IT non dovrebbe sceglierli da sola.
4. Quantificate i costi delle opzioni. AWS consiglia che, se la strategia di ripristino costa più del guasto da cui protegge, "non dovrebbe essere adottata a meno che non ci sia una motivazione secondaria come requisiti normativi".
5. Progettate e testate. Realizzate i meccanismi di backup, replica e failover, poi eseguite un test e registrate il tempo e il punto di ripristino effettivamente raggiunti.
6. Rivedete ogni anno e dopo i cambiamenti importanti. I sistemi passano da un livello all'altro con l'evolvere del business.

Quali tecnologie rispettano quali obiettivi?

• Backup e snapshot pianificati si adattano a RPO di ore. Proteggono bene da corruzione e cancellazione perché ogni copia è un punto fisso nel tempo.
• Il point-in-time recovery (backup dei log del database) porta l'RPO dei database a pochi minuti.
• La replica asincrona verso un'altra region dà un RPO da secondi a minuti, a seconda del ritardo di replica.
• La replica sincrona tra Availability Zone dà un RPO vicino a zero, al prezzo di una maggiore latenza in scrittura. Le linee guida Azure Well-Architected sul disaster recovery di Microsoft suggeriscono la replica sincrona tra zone per i dati ad alta priorità e quella asincrona tra region per i dati a priorità più bassa.
• Ambienti di standby e automazione (pilot light, warm standby, infrastructure as code, failover DNS scriptato) riducono l'RTO.

Attenzione alla trappola della replica. AWS osserva che la replica continua "può non proteggere da eventi disastrosi come corruzione dei dati o attacchi dolosi" tanto quanto i backup point-in-time. Un database cifrato da ransomware si replica con la stessa rapidità di uno sano, quindi conservate copie point-in-time accanto alle repliche.

Come dimostrare di rispettare gli obiettivi

Misurate, non presumete. A ogni test di DR annotate quando è iniziata l'interruzione, quando il piano è stato attivato, quando il servizio è tornato e l'orario dell'ultima transazione recuperata. Da questi dati ricavate RTO e RPO effettivi. Le indicazioni di Microsoft raccomandano un mix di esercitazioni tabletop, prove a secco in ambienti non di produzione e simulazioni a livello di produzione. Monitorate i risultati nel tempo e correggete per primo il passaggio più lento.

Come aiuta Opsio

Opsio conduce workshop di business impact, fissa RTO/RPO per livello con i vostri responsabili di business e realizza e testa la corrispondente architettura di ripristino su AWS e Azure con il suo servizio di cloud disaster recovery. Per la piattaforma SaaS di recruiting WorkBuster, un approccio a downtime quasi nullo era un requisito imprescindibile quando Opsio ha spostato la piattaforma su AWS. L'architettura usa un database MySQL multi-AZ ad alta disponibilità su Amazon RDS, con l'infrastruttura definita in template CloudFormation.

Domande frequenti

Qual è la differenza tra RTO e RPO?

L'RTO è per quanto tempo un sistema può essere non disponibile dopo un'interruzione. L'RPO è quanti dati, misurati in tempo, potete permettervi di perdere. L'RTO riguarda il fermo; l'RPO riguarda la perdita di dati.

Quali sono un buon RTO e un buon RPO?

Non esiste un numero universale. Un sistema di pagamento può richiedere minuti per entrambi, mentre uno strumento interno di reportistica può accettare 24 ore. Ricavate gli obiettivi dal costo di fermo e perdita di dati di ciascun processo aziendale, poi verificate il costo per rispettarli.

L'RPO può essere zero?

Vicino a zero, sì, con replica sincrona o architetture multi-sito active/active. Una perdita di dati davvero nulla è difficile da garantire tra region a causa di distanza e latenza, e la sola replica non protegge dalla corruzione.

L'RTO è la stessa cosa di uno SLA?

No. Uno SLA è una promessa ai clienti su disponibilità o tempi di risposta. L'RTO è un obiettivo interno di ripristino per uno scenario di disastro. Il vostro RTO dovrebbe supportare i vostri SLA, ma si misurano in modo diverso.

Ogni quanto vanno rivisti gli obiettivi di ripristino?

Almeno una volta l'anno e dopo i cambiamenti importanti a sistemi, fornitori o business. Rimisurateli a ogni test di DR, perché contano i valori effettivamente raggiunti.