Le due domande a cui rispondono
Quando un sistema si ferma, le domande sono due. Entro quando deve tornare a funzionare? E quanti dati possiamo permetterci di perdere? RTO e RPO sono le risposte, scritte e decise prima che succeda.
RTO (Recovery Time Objective): il tempo massimo entro cui un servizio deve tornare operativo dopo un'interruzione.
RPO (Recovery Point Objective): la quantità massima di dati che si accetta di perdere, espressa in tempo: quanto indietro può trovarsi l'ultimo punto di ripristino utile.
Un esempio: se il gestionale ha un RPO di 4 ore e un RTO di 8 ore, in caso di guasto si accetta di perdere al massimo le ultime quattro ore di lavoro e di riavere il sistema funzionante entro otto ore dall'interruzione.
RTO guarda avanti, RPO guarda indietro
Il modo più semplice per non confonderli è immaginarli su una linea del tempo, con l'incidente al centro. L'RPO misura verso il passato: fino a quale momento i dati sono salvi. L'RTO misura verso il futuro: quando si torna a lavorare.
Sono indipendenti tra loro. Un sistema può avere un RPO molto stretto e un RTO largo (i dati sono replicati quasi in tempo reale, ma rimettere in piedi l'applicazione richiede una giornata), oppure il contrario.
| RPO | RTO | |
|---|---|---|
| Domanda | Quanti dati posso perdere? | Quanto posso restare fermo? |
| Direzione | Dal guasto verso il passato | Dal guasto verso il futuro |
| Dipende da | Frequenza e tipo delle copie | Procedure, infrastruttura di ripristino, persone |
| Si migliora con | Backup più frequenti, replica, snapshot | Automazione, ambienti pronti, procedure provate |
Come si definiscono: dai processi, non dai server
L'errore più comune è partire dalla tecnologia: “il backup gira di notte, quindi l'RPO è di 24 ore”. Così si descrive quello che c'è, non quello che serve. La strada corretta è l'inverso: si parte dai processi aziendali e si chiede a chi li gestisce quanto costa fermarli.
- Elenca i processi critici: fatturazione, produzione, logistica, assistenza ai clienti. Per ognuno, i sistemi da cui dipende.
- Stima l'impatto del fermo nel tempo: cosa succede dopo un'ora, dopo mezza giornata, dopo tre giorni. È il cuore di una business impact analysis. Per la parte economica puoi partire dal simulatore del costo del fermo.
- Stima l'impatto della perdita di dati: quanto lavoro andrebbe rifatto, e se si può rifare. Gli ordini arrivati via email si recuperano; transazioni di cassa o misure di produzione spesso no.
- Decidi i valori insieme al business: RTO e RPO sono scelte economiche, non tecniche. Più sono stretti, più costa la soluzione che li garantisce.
- Solo a questo punto scegli la tecnologia: frequenza dei backup, replica, ambienti di ripristino, contratti con i fornitori.
Non tutti i sistemi valgono uguale
Dare a tutto lo stesso RTO è il modo più rapido per spendere troppo sui sistemi secondari e troppo poco su quelli critici. Di solito si ragiona per livelli. I valori qui sotto mostrano solo come si presenta una classificazione, non sono uno standard: vanno ricavati dall'analisi della tua azienda.
| Livello | Esempi | RTO | RPO |
|---|---|---|---|
| Critico | ERP, e-commerce, sistemi di produzione | Poche ore | Minuti |
| Importante | Posta, file condivisi, CRM | Una giornata | Alcune ore |
| Differibile | Archivi, intranet, ambienti di test | Alcuni giorni | 24 ore o più |
Attenzione alle dipendenze: il gestionale “critico” non riparte se prima non ripartono i servizi di cui ha bisogno, come autenticazione, DNS, rete e licenze. Il loro RTO non può essere più largo di quello dei sistemi che li usano.
Un RTO non testato è un'ipotesi
Il numero scritto nel piano vale solo se è stato misurato. E l'RTO reale comprende molto più del tempo di copia dei dati: accorgersi del problema, decidere di ripristinare, recuperare le credenziali, preparare l'ambiente, ripristinare, verificare che tutto funzioni, avvisare gli utenti.
Per questo le prove di ripristino vanno pianificate e messe a verbale, con i tempi reali. Nella storia Il venerdì sera in cui i file cambiarono nome raccontiamo cosa cambia quando l'ultima prova risale a poche settimane prima: il tempo necessario per rimettere in piedi il gestionale era già noto.
- i backup falliscono senza che arrivi un avviso a qualcuno;
- nessuno ha mai ripristinato un intero sistema, solo singoli file;
- le copie sono raggiungibili con le stesse credenziali dei server, e un attacco può cancellarle insieme agli originali;
- i dati nei servizi cloud, per esempio posta e documenti in Microsoft 365, non hanno un backup indipendente.
Gli errori più frequenti
- Numeri scelti dall'IT da solo. Senza il business, RTO e RPO descrivono l'infrastruttura, non il rischio.
- Un solo valore per tutto. Si paga il massimo ovunque, oppure si protegge male ciò che conta.
- Dimenticare il ransomware. Un guasto hardware si risolve con l'ultima copia; un attacco può aver colpito anche le copie, o essere iniziato settimane prima. Serve almeno una copia isolata o immutabile: ne parliamo nella guida sulla regola del backup 3-2-1.
- Non rivederli mai. Nuovi sistemi, nuove sedi e nuovi processi cambiano le priorità: RTO e RPO vanno riesaminati periodicamente e a ogni cambiamento significativo.
In sintesi
L'RPO dice quanti dati puoi perdere, l'RTO quanto tempo puoi restare fermo. Si decidono partendo dal costo del fermo, si differenziano per criticità e valgono solo se misurati con prove di ripristino reali.