RTO e RPO: differenze, esempi e come misurarli davvero

TL;DR

RTO è quanti minuti puoi stare fermo. RPO è quanti minuti di lavoro puoi perdere. Sono due numeri diversi, hanno costi molto diversi e vengono confusi quasi sempre. Vediamoli con esempi concreti su un'azienda da 80 dipendenti.

Le definizioni che servono

• RTO (Recovery Time Objective) — il tempo massimo accettabile dal disastro al ritorno all'operatività.
• RPO (Recovery Point Objective) — la quantità massima di dati che l'azienda è disposta a perdere, espressa in tempo (di solito minuti o ore).

Entrambi si misurano partendo dalla Business Impact Analysis (BIA): per ogni processo critico, quanto costa il fermo (RTO) e quanto costa rifare il lavoro (RPO).

Esempi concreti

Prendiamo tre processi tipici di una PMI con un ERP, posta e file server.

Caso 1 — ERP fatturazione

• Costo del fermo: ~1.200 €/ora di mancato fatturato.
• Costo della perdita dati: ogni ordine non registrato va richiamato a mano. ~30 minuti di lavoro per ordine.
• Numeri target: RTO 30 minuti, RPO 15 minuti.

Caso 2 — Posta elettronica

• Costo del fermo: stallo nella comunicazione con clienti. Difficile da quantificare ma alto.
• Costo della perdita dati: ogni mail persa = potenziale rischio commerciale.
• Numeri target: RTO 15 minuti, RPO 5 minuti.

Caso 3 — File server documentale

• Costo del fermo: medio, le persone possono lavorare offline.
• Costo della perdita dati: alto se sono documenti firmati.
• Numeri target: RTO 60 minuti, RPO 60 minuti.

L'errore #1: RTO basso senza il budget

In sede commerciale è facile dichiarare "RTO 5 minuti, RPO 1 minuto". In pratica costa 4-6× quanto un RTO/RPO da 30/15 minuti. Il salto da minuti a secondi richiede:

• replica continua (CDP) invece di snapshot a intervalli;
• failover automatico, non manuale;
• collegamento dedicato fra siti (non Internet).

Il primo passo è capire il vero costo del fermo per processo. Spesso, calcolato bene, un RTO di 30 minuti basta per il 90% delle PMI.

L'errore #2: confondere RPO e frequenza di backup

Un backup ogni 4 ore non significa RPO di 4 ore. Significa che, nel peggiore dei casi, si perdono fino a 4 ore meno il tempo di propagazione dei dati al sito DR. In una settimana media i numeri sono migliori; in una giornata sfortunata sono peggiori.

Se il vostro contratto cliente promette RPO 15 minuti, il backup deve essere ogni 15 minuti e la replica deve essere completata entro 15 minuti dal primo evento.

Come misurare RTO e RPO veri

Il modo onesto è un test. Una procedura semplice:

1. Pianificate una finestra di test di 2 ore.
2. Spegnete (in test) il sistema target.
3. Eseguite il runbook DR cronometrando ogni step.
4. Verificate il tempo totale (= RTO reale).
5. Verificate l'ultimo dato presente nel sistema ricoverato (= RPO reale).

Documentate. Se i numeri non rientrano negli obiettivi, avete un problema documentato (e un piano d'azione).

La trappola del "RPO zero"

L'RPO zero (replica sincrona) esiste, ma:

• richiede latenza < 5 ms fra siti;
• richiede banda dedicata, non Internet;
• raddoppia il costo dell'infrastruttura.

In Italia "RPO zero" è realistico fra siti dello stesso datacenter o fra città vicine con dark fiber. Per un DR cloud distribuito, il minimo onesto è RPO ~5 secondi con CDP basato su block replication.

FAQ

RTO e RPO devono essere uguali?

No. Sono due dimensioni indipendenti. Un sistema può avere RTO basso (riparte presto) e RPO alto (perde alcune ore di dati), per esempio un sistema di reporting batch.

Chi approva ufficialmente RTO e RPO?

Il management aziendale, idealmente con firma del CFO o del COO. Sono numeri di business, non tecnici.

Quanto durano "validamente" RTO e RPO definiti?

In media 12-18 mesi. Cambi di processo, M&A, nuovi sistemi: vanno rivisti.

Per il metodo di calcolo dell'RTO, leggi Come calcolare il tuo RTO reale. Per scegliere fra snapshot e replica continua, vedi Snapshot vs replica continua.