RTO e RPO

Cos'è

RTO (Recovery Time Objective) è il tempo massimo accettabile che un sistema può restare fermo dopo un incidente prima che il danno diventi inaccettabile per il business: se il tuo ERP ha un RTO di 4 ore, vuol dire che oltre quella soglia il costo del fermo — ordini bloccati, produzione ferma, clienti che chiamano — diventa insostenibile, non solo fastidioso. RPO (Recovery Point Objective) è invece la quantità massima di dati che puoi permetterti di perdere, misurata in tempo: un RPO di 1 ora significa che, nel peggiore dei casi, perdi al massimo un'ora di lavoro dall'ultimo backup utile, il che dice anche con quale frequenza quel backup deve girare — un RPO di un'ora richiede backup orari o replica continua, non un job notturno. I due valori sono collegati ma indipendenti: un sistema può avere RTO stretto e RPO più largo, o viceversa, a seconda di cosa fa davvero male perdere — il tempo o i dati.

Perché conta

Senza questi due numeri, definiti sistema per sistema e concordati con il business — non decisi a tavolino dall'IT per comodità — un piano di disaster recovery resta un'intenzione vaga, il classico documento scritto una volta e mai più aperto. Sono anche il modo con cui si giustifica economicamente l'infrastruttura di backup e ridondanza davanti a chi tiene i cordoni della borsa: un RTO/RPO molto stretti costano molto di più da garantire (repliche sincrone, siti di failover, licenze duplicate), e non tutti i sistemi li meritano allo stesso modo. Un file server interno può permettersi un RTO di un giorno senza che nessuno se ne accorga davvero; un sistema di pagamento o un e-commerce no, lì ogni minuto fermo ha un costo misurabile. Definirli per iscritto obbliga anche a una conversazione scomoda ma necessaria con il business: quanto siete disposti a spendere per quanto tempo di fermo evitato.

Come li calcolo per ogni sistema

In pratica il punto di partenza è sempre una business impact analysis: per ogni sistema critico chiedo al responsabile di funzione, non al collega IT, cosa succede concretamente se quel sistema si ferma per un'ora, per quattro, per un giorno — e a che punto il danno diventa irreversibile o troppo costoso. Da lì si costruiscono le fasce (tier 1, 2, 3) con RTO/RPO diversi e si dimensiona l'infrastruttura di conseguenza, invece di comprare la stessa soluzione di backup per tutto il parco macchine. L'ultimo passaggio, quello che quasi tutti saltano, è testare davvero il ripristino: un RTO scritto su un documento e mai verificato con un test di failover reale è solo un numero di fantasia. Per strutturare il processo mi appoggio ancora alla metodologia descritta nel NIST SP 800-34, la guida di riferimento per il contingency planning.

// Nota pratica

Il primo errore comune è impostare RTO/RPO identici per tutti i sistemi 'per semplicità': quasi sempre significa sovra-investire su ciò che conta poco e sotto-proteggere ciò che conta davvero. Va fatto un'analisi per sistema, basata sull'impatto reale di business, non sulla comodità tecnica.