RPO e RTO sono due domande travestite da sigla. RPO (Recovery Point Objective, obiettivo del punto di ripristino) chiede: «quante ore o giorni di dati possiamo permetterci di perdere?». RTO (Recovery Time Objective, obiettivo del tempo di ripristino) chiede: «quanto tempo possiamo restare fermi prima che il danno diventi serio?». Non sono numeri che escono da uno standard: sono decisioni dell'azienda, e da quelle decisioni dipendono gli investimenti in backup e continuità.
RPO: quanto indietro puoi tornare
Il RPO misura la perdita di dati tollerabile. Se fai una copia ogni notte e il sistema si guasta alle 17, perdi il lavoro della giornata: il tuo RPO effettivo è di circa un giorno. Se per te perdere una giornata di ordini è inaccettabile, quel RPO è sbagliato, anche se il backup «funziona».
Ridurre il RPO significa copiare più spesso o in modo continuo, e questo ha un costo: spazio di archiviazione, traffico di rete, complessità. Per questo il RPO si decide sistema per sistema: la contabilità e gli ordini possono meritare un RPO di pochi minuti, l'archivio storico forse di una settimana. La domanda da porre in riunione è semplice: «se domani mattina ripartiamo dall'ultima copia, cosa abbiamo perso e chi ne subisce le conseguenze?».
RTO: quanto tempo per ripartire
L'RTO misura il fermo tollerabile: dal momento del guasto al momento in cui il servizio torna utilizzabile. Anche qui il valore dipende dal sistema. Un sito vetrina può stare fermo qualche ora senza drammi; il gestionale che gestisce spedizioni e fatture, in certi periodi, no.
Attenzione a un punto spesso trascurato: l'RTO non è il tempo che il software di backup impiega a copiare i dati indietro. Include individuare il problema, decidere chi interviene, preparare l'ambiente, ripristinare, verificare che tutto funzioni e comunicare la ripresa. Le prove di ripristino programmate servono proprio a misurare questo tempo reale, che è quasi sempre più lungo di quello immaginato a tavolino.
Chi decide questi valori, e con quali informazioni
RPO e RTO li fissa l'azienda, non il fornitore e non uno standard. Le guide di riferimento — come la funzione Recover del NIST Cybersecurity Framework 2.0, pensato anche per le piccole imprese — indicano di pianificare il recupero, ma non prescrivono numeri: sono riferimenti volontari. La decisione spetta a chi risponde del risultato economico, cioè al titolare o all'amministratore delegato, su proposta di chi conosce i sistemi.
Per decidere servono tre informazioni, nessuna delle quali è solo tecnica:
- il costo del fermo: ordini persi, penali, clienti che non riescono a lavorare con te, ore del personale pagate senza produzione;
- il costo della perdita dati: rifare il lavoro di un'ora, di un giorno o di una settimana, e gli eventuali effetti su obblighi contabili o contrattuali;
- il costo della protezione: quanto serve spendere, in strumenti e organizzazione, per passare da un RPO di un giorno a uno di un'ora, o da un RTO di due giorni a uno di quattro ore.
Quando questi tre numeri sono sul tavolo, la scelta diventa un normale ragionamento d'impresa: si investe finché il costo della protezione resta sensato rispetto al danno evitato. I valori scelti vanno scritti, approvati e riesaminati quando l'azienda cambia — nuovi clienti, nuovi sistemi, nuovi obblighi.
Esempio illustrativo: la giornata di vendite sparita
Esempio illustrativo. Lo scenario seguente è inventato per ragionare sui due parametri; non descrive un caso reale né un cliente.
Un'azienda commerciale con tre punti vendita e un piccolo sito di ordini online scopre un guasto al server centrale un martedì mattina. L'ultimo backup risale alla domenica notte: spariscono tutti gli scontrini e gli ordini del lunedì. Il titolare si rende conto di due cose. Primo, il RPO effettivo era di oltre ventiquattro ore, mentre lui pensava fosse «il backup c'è tutte le notti»: bastava una copia ogni ora per ridurre la perdita, e ora sa quanto vale quella scelta. Secondo, l'RTO previsto sulla carta era «un giorno», ma tra reperibilità del tecnico, consegna del nuovo disco e riconfigurazione del gestionale il fermo reale è durato tre giorni. Dopo l'episodio, l'azienda fissa per iscritto valori diversi per ogni sistema — ordini e cassa con RPO di un'ora e RTO di mezza giornata, archivio documentale con RPO di una settimana — e calendarizza una prova di ripristino per verificare che i tempi reali coincidano con quelli decisi.
Verificare che gli obiettivi reggano alla prova
Un RPO scritto in un documento non è un RPO reale: lo è solo se le copie avvengono davvero con quella frequenza e si completano. Un RTO è credibile solo se una prova ha dimostrato che il ripristino rientra in quel tempo. Se realtà e obiettivi non coincidono, ci sono due strade, entrambe legittime: investire per adeguare la realtà, oppure ridiscutere l'obiettivo se il costo non è sostenibile. Ciò che non funziona è lasciare la discrepanza nascosta, perché si scopre sempre nel momento peggiore.
Anche la guida NIST SP 1339 sui backup, nata per gli ambienti industriali, insiste su principi trasferibili a qualsiasi organizzazione: copie regolari, test periodici e riesame durante le esercitazioni di recupero. È il metodo che mantiene allineati obiettivi e pratica; per la struttura delle copie può aiutare anche la regola 3-2-1 riletta oggi.
Il contributo di OverZeus
OverZeus non calcola RPO e RTO al posto tuo e non esegue i backup: quei valori restano una decisione dell'azienda, presa con le informazioni descritte sopra. Il contributo è sul versante del controllo continuo, tramite le integrazioni concordate con le piattaforme esistenti. Penelope, l'agente dedicato a backup e continuità, sorveglia le copie e la preparazione al ripristino sulle piattaforme collegate: segnala se i job non si completano con la frequenza attesa o se una prova di ripristino prevista non risulta eseguita. Odysseus coordina: collega questi segnali con il resto del quadro — per esempio un sistema diventato più critico dopo un cambiamento — e li riunisce in una sintesi comprensibile per chi deve decidere, con proposte e conseguenze esplicitate prima di qualsiasi intervento attivo, che richiede sempre l'approvazione prevista.
Così la domanda «realtà e obiettivi coincidono?» smette di avere una risposta solo una volta l'anno, quando si rifà il documento, e diventa un confronto continuo tra ciò che è stato deciso e ciò che viene osservato.
Domande frequenti su RPO e RTO
Come si traducono RPO e RTO in decisioni di investimento?
Mettendo a confronto il costo del fermo e della perdita dati con il costo della protezione. Ogni miglioramento dei due valori ha un prezzo: si investe dove il danno evitato lo giustifica, sistema per sistema, e si documenta la scelta.
Chi in azienda deve fissare questi valori?
La proprietà o la direzione, su proposta di chi gestisce i sistemi e con il contributo di chi conosce i processi (amministrazione, vendite, produzione). Chi decide deve rispondere del rischio; chi propone deve rendere le opzioni comprensibili.
Cosa succede se realtà e obiettivi non coincidono?
Che gli obiettivi valgono solo sulla carta. Si corregge la realtà con investimenti mirati oppure si ridiscutono gli obiettivi, ma la discrepanza va resa visibile e gestita: tenerla nascosta significa scoprirla durante il prossimo incidente.
Due numeri, una conversazione
RPO e RTO sono lo strumento più semplice per far parlare la stessa lingua a titolare e tecnici: quanto possiamo perdere, quanto possiamo stare fermi, quanto costa migliorare. Una volta decisi, vanno verificati con prove regolari e aggiornati quando l'azienda cambia. Il passo successivo naturale è organizzare quelle verifiche in un runbook di ripristino e controllare che ogni backup completato sia davvero utilizzabile.
Vuoi un quadro continuo di backup, prove e scostamenti rispetto agli obiettivi che hai fissato? Partiamo dagli strumenti che già usi.
Valuta il monitoraggio dei backup e delle prove di ripristino già in uso
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.