RTO e RPO: cosa sono, differenze e come calcolarli

Nel definire una strategia di resilienza aziendale, non si può non incrociare questi due acronimi: RTO e RPO. Sebbene spesso citati insieme, rappresentano concetti molto diversi e rispondono a due delle domande più critiche che ogni IT Manager o CIO deve porsi di fronte a un potenziale disastro: “Quanto tempo abbiamo per ripartire?” e “Quanti dati possiamo permetterci di perdere?“.

Comprendere a fondo il loro significato, le loro differenze e, soprattutto, il processo per calcolarli correttamente è importante per elaborare un piano di continuità operativa che rappresenta un vero e proprio strumento di business efficace.

Valori errati o definiti senza un’analisi approfondita possono portare a investimenti sbagliati, a un falso senso di sicurezza e a conseguenze operative devastanti in caso di incidente.

Questa guida tecnica è pensata per fare chiarezza. Non ci limiteremo a darti le definizioni, ma ti mostreremo le differenze chiave, ti guideremo attraverso un processo pratico per calcolare i valori corretti per la tua azienda e ti faremo vedere come questi due parametri influenzano ogni scelta tecnologica e strategica del tuo piano di disaster recovery

Cosa sono RTO e RPO: le definizioni chiave

Prima di metterli a confronto, diamo delle definizioni precise di ciascuna metrica. Entrambe sono misurate in unità di tempo (secondi, minuti, ore), ma si riferiscono a due aspetti completamente diversi del processo di ripristino.

Recovery Time Objective (RTO)

L’RTO, o Recovery Time Objective, rappresenta il tempo massimo di inattività che la tua azienda può tollerare per una specifica applicazione, un sistema o un processo dopo un’interruzione.

In altre parole, risponde alla domanda strategica: “Quanto tempo può rimanere offline questo sistema prima di causare un danno operativo ed economico grave?”.

Un RTO basso (vicino allo zero) implica la necessità di tecnologie di failover automatico e infrastrutture ridondanti, mentre un RTO più alto (ore o giorni) può essere gestito con procedure di ripristino manuali o più lente. Questo parametro dunque definisce la rapidità con cui l’intero sistema deve tornare operativo.

Recovery Point Objective (RPO)

L’RPO, o Recovery Point Objective, definisce invece, la quantità massima di dati che la tua azienda è disposta a perdere a seguito di un incidente. Viene misurato come il tempo che intercorre tra l’ultimo backup valido e il momento del disastro.

La domanda a cui risponde è: “A quale punto nel tempo dobbiamo essere in grado di tornare indietro?”.

Un RPO basso (pochi secondi o minuti) richiede tecnologie di backup o replica dei dati molto frequenti, quasi continue. Un RPO più alto (diverse ore) indica che l’azienda può tollerare la perdita dei dati generati dall’ultimo backup programmato. Questo parametro definisce la freschezza dei dati al momento del ripristino.

RTO vs RPO: le differenze fondamentali a confronto

Ora che le definizioni sono chiare, mettiamo i due concetti a confronto diretto per evidenziarne le differenze operative e strategiche.

Come puoi vedere, RTO e RPO sono due aspetti complementari della resilienza della tua azienda. Lavorano insieme per definire i requisiti completi del tuo piano, ma agiscono su leve tecnologiche e operative completamente diverse.

Come calcolare RTO e RPO per la tua azienda

Non esistono valori di RTO e RPO universali, validi per tutte le tipologie di attività. Ogni azienda, e ogni applicazione all’interno di essa, ha infatti esigenze diverse. Per definire correttamente i valori di RTO e RPO è necessario seguire un processo analitico.

Ecco come farlo in tre step:

1. Eseguire una Business Impact Analysis (BIA): il punto di partenza è sempre un’analisi approfondita dell’impatto sul business. La BIA è il processo attraverso cui identifichi le funzioni e le applicazioni aziendali e le classifichi in base alla loro criticità. Per ogni processo, devi chiederti: “Qual è l’impatto finanziario e operativo se questo servizio si ferma per un’ora? Per un giorno? Per una settimana?”. Questa analisi ti permette di creare una gerarchia chiara, distinguendo i sistemi critici (da cui dipende la sopravvivenza del business), quelli importanti e quelli meno essenziali.
2. Definire RTO e RPO per ogni servizio: una volta completata la classificazione, puoi assegnare a ogni servizio o applicazione una coppia di valori RTO e RPO. Un sistema ERP, critico per la produzione, avrà probabilmente un RTO di pochi minuti e un RPO di pochi secondi. Un server di sviluppo, al contrario, potrebbe avere un RTO di 24 ore e un RPO di 12 ore. Questo approccio granulare ti permette di ottimizzare gli investimenti, concentrando le risorse sulle tecnologie più performanti, ossia solo dove è veramente necessario.
3. Coinvolgere i responsabili di business: questa non è una decisione puramente tecnica. Il team IT può fornire le opzioni tecnologiche e i relativi costi, ma la decisione finale su quanto tempo di inattività e quanta perdita di dati siano tollerabili deve essere presa in collaborazione con i responsabili dei vari reparti. Sarà il responsabile vendite a poter quantificare l’impatto del fermo del CRM, e il responsabile della logistica a poter definire le conseguenze del blocco del sistema di gestione del magazzino.

Il ruolo strategico di RTO e RPO nel disaster recovery

RTO e RPO sono due metriche fondamentali su cui si progetta e si costruisce l’intero piano di Disaster Recovery. Sono infatti i requisiti di business che dettano le scelte tecnologiche, e non il contrario.

È sulla base di questi due valori che tu e il tuo team potrete prendere decisioni informate su:

• Tecnologie di backup: la frequenza (e quindi l’RPO) determina se è sufficiente un backup notturno, orario o se è necessaria una protezione continua dei dati.
• Siti di ripristino: un RTO molto basso potrebbe richiedere un sito di disaster recovery “hot site”, sempre attivo e pronto al failover, mentre un RTO di diverse ore potrebbe accontentarsi di un “cold site” da attivare al bisogno.
• Costi e budget: esiste una relazione diretta tra i valori di RTO/RPO e i costi. RTO e RPO vicini allo zero richiedono tecnologie complesse e costose. Definire valori realistici e basati sulla BIA permette di costruire una soluzione che sia tecnicamente efficace ed economicamente sostenibile.

RTO e RPO in pratica: esempi per diversi scenari

Per rendere i concetti ancora più tangibili, analizziamo tre scenari aziendali comuni con diversi livelli di criticità.

Esempio 1 (alta criticità)

Un sito di vendita online che processa centinaia di transazioni all’ora.

• RTO: Pochi minuti. Ogni minuto di downtime si traduce in una perdita diretta di vendite e in un danno d’immagine. È necessario un failover quasi istantaneo.
• RPO: Pochi secondi. Perdere anche solo un minuto di transazioni (nuovi ordini, dati dei clienti) sarebbe inaccettabile e complesso da recuperare.

Esempio 2 (media criticità)

Un server utilizzato dai dipendenti per condividere documenti interni durante l’orario di lavoro.

• RTO: 2-4 ore. Un’interruzione è un problema, ma i dipendenti possono temporaneamente lavorare su altri compiti. Il ripristino entro mezza giornata è un obiettivo ragionevole.
• RPO: 1 ora. Un backup orario è sufficiente. In caso di ripristino, si perderebbe al massimo un’ora di lavoro sui documenti, una quantità di dati gestibile da recuperare.

Esempio 3 (bassa criticità)

Un sistema che archivia dati a cui si accede raramente per scopi di consultazione o compliance.

• RTO: 24-48 ore. L’impatto di un fermo non è immediato. C’è tempo per pianificare un ripristino senza urgenza.
• RPO: 24 ore. I dati non cambiano frequentemente. Un backup notturno è più che adeguato per garantire la protezione delle informazioni.

Domande frequenti su RTO e RPO

Infine, rispondiamo ad alcune delle domande più comuni per chiarire ogni dubbio residuo su queste metriche fondamentali.

In poche parole, qual è la differenza tra RTO e RPO?

La differenza è semplice: l’RTO riguarda il tempo (quanto velocemente devi ripartire), mentre l’RPO riguarda i dati (quanti ne puoi perdere). L’RTO misura il tempo di inattività, l’RPO la perdita di informazioni.

Un RTO/RPO pari a zero è sempre l’obiettivo?

No, e perseguirlo ciecamente è un errore comune. Un RTO/RPO pari a zero (o quasi) è tecnicamente possibile ma richiede investimenti tecnologici molto significativi. L’obiettivo non è raggiungere lo zero per tutti i sistemi, ma definire i valori giusti e sostenibili per ogni servizio in base alla sua reale criticità per il business.

Come si legano RTO/RPO alla Business Continuity?

Sono le metriche operative che traducono gli obiettivi strategici di una strategia di Business Continuity in requisiti tecnici. La Business Continuity definisce “quali” processi devono continuare a funzionare; RTO e RPO definiscono “in quanto tempo” e “con quale perdita di dati” devono essere ripristinati per garantire tale continuità.

Questi valori devono essere aggiornati nel tempo?

Assolutamente sì. L’azienda evolve, nuove applicazioni vengono introdotte e la criticità dei processi può cambiare. È fondamentale rivedere e, se necessario, aggiornare i valori di RTO e RPO periodicamente (almeno una volta all’anno) e ogni volta che ci sono cambiamenti significativi nell’infrastruttura o nel modello di business.