L’obiettivo di punto di ripristino (RPO) è la quantità massima di dati — misurata in termini di tempo — che la vostra organizzazione può perdere a seguito di un’interruzione imprevista e continuare comunque a operare entro limiti accettabili.

Pensate all’RPO come a un orologio che segna la perdita dei dati: inizia a scorrere all’indietro dal momento in cui si verifica un’interruzione di servizio, un attacco informatico o un errore umano, e si ferma all’ultimo backup o punto di replica utilizzabile. Ogni secondo che intercorre tra questi due punti rappresenta dati che potreste non recuperare mai più.

NISTdefinisce l’RPOcome «il momento nel tempo a cui i dati devono essere ripristinati dopo un’interruzione». Tale definizione appare ingannevolmente semplice. In pratica, la definizione del giusto RPO solleva questioni importanti riguardo a quali carichi di lavoro siano più rilevanti, alla frequenza dei backup e all’entità degli investimenti nell’infrastruttura di replica.

Gli attacchi informatici, le interruzioni del servizio cloud e le cancellazioni accidentali si verificano in momenti che sfuggono al vostro controllo. Le organizzazioni che definiscono chiari obiettivi RPO — e li garantiscono tramite un sistema di backup automatizzato e basato su criteri — si mettono nelle condizioni di ripristinare i dati entro i limiti di tolleranza aziendali, anziché trovarsi a dover correre ai ripari a posteriori.

Questa guida illustra il funzionamento dell’RPO, le differenze rispetto all’obiettivo di tempo di ripristino (RTO), alcuni esempi concreti, il calcolo dell’RPO e il ruolo fondamentale dell’RPO nella resilienza informatica.

Come funziona l’RPO nella pianificazione della continuità operativa

L’RPO è il “timer di perdita dei dati” che determina la frequenza dei backup. Se l’RPO per un database è di un’ora, i backup dovrebbero essere eseguiti almeno ogni 60 minuti. Se non si rispetta questa cadenza, si rischia di aver già superato la soglia di tolleranza prima ancora che si verifichi un problema.

In un piano di continuità operativa, l’RPO costituisce, insieme all’RTO, uno dei due pilastri del ripristino. Mentre l’RTO risponde alla domanda “In quanto tempo possiamo riportare in funzione i sistemi?”, l’RPO risponde alla domanda “Quanto saranno aggiornati i dati ripristinati?”. Entrambi contribuiscono alla più ampia strategia di Recovery di emergenza — ed entrambi dovrebbero essere verificati tramite test regolari, non solo documentati in un raccoglitore.

L’RPO può avere anche una dimensione legata alla conformità:

• Normative come l’HIPAA prevedono generalmente che le organizzazioni sanitarie conservino copie recuperabili delle informazioni sanitarie elettroniche dei pazienti.
• La legge SOX prevede disposizioni volte a garantire che i documenti contabili siano verificabili e integri.
• Il GDPR prevede che il trattamento dei dati personali debba poter essere ripristinato tempestivamente a seguito di un incidente tecnico.

Quando un attacco crittografa i dati di produzione, la differenza tra l’ultimo backup integro e il timestamp della crittografia corrisponde ai dati che si perdono. Quella differenza rappresenta l’RPO in azione – e contribuisce a determinare se il ripristino richiederà alcune ore o si trasformerà in una crisi.

Conclusione pratica: l’RPO non è un valore che si imposta una volta per tutte e poi si dimentica. Dovrebbe riflettere i tassi attuali di modifica dei dati, i requisiti di conformità e la realtà del panorama delle minacce – e dovrebbe essere applicato tramite politiche di backup automatizzate.

RPO e RTO: qual è la differenza?

RPO e RTO sono le due facce della stessa medaglia in materia di Recovery, ma misurano aspetti diversi.

L’RPO guarda a ritroso a partire dal momento del guasto. Si chiede: “Quanti dati possiamo permetterci di perdere?”. La risposta è espressa in termini di tempo — minuti, ore o giorni — e rappresenta l’intervallo tra l’ultimo backup valido e l’interruzione del servizio.

L’RTO guarda al futuro a partire dal momento del guasto. Si chiede: “In quanto tempo i sistemi devono tornare operativi?” Anche la risposta è espressa in termini di tempo, ma misura la tolleranza al tempo di inattività piuttosto che quella alla perdita di dati.

Entrambe le metriche dovrebbero essere definite congiuntamente. Un’organizzazione con un RPO di 15 minuti ma un RTO di 24 ore ha dati recenti che rimangono inattivi per un giorno intero. Al contrario, un RTO di quattro ore abbinato a un RPO di 24 ore significa che i sistemi tornano operativi rapidamente                                                                                                     

Allineare gli obiettivi RPO e RTO prima che si verifichi un incidente — e verificarne la validità attraverso test periodici di Recovery — può fare la differenza tra una risposta ben pianificata e una situazione di caos.

Livelli di RPO ed esempi concreti

Non tutti i carichi di lavoro richiedono lo stesso RPO. Classificare gli RPO in base alla criticità aziendale aiuta a garantire una protezione rigorosa dove è necessario e a mantenere i costi sotto controllo dove non lo è.

Livello 0: RPO quasi pari a zero (da secondi a minuti): i database delle transazioni finanziarie, le cartelle cliniche elettroniche dei pazienti e le piattaforme di trading in tempo reale richiedono in genere una protezione continua dei dati (CDP) o una replica sincrona. Questi carichi di lavoro generano ricavi o hanno un peso normativo ogni secondo, quindi anche pochi minuti di perdita di dati possono essere difficili da assorbire. Le organizzazioni che implementano un RPO quasi pari a zero utilizzano in genere la CDP o la replica sincrona per ridurre al minimo la finestra di perdita dei dati.

Livello 1: da 1 a 4 ore: in questa categoria rientrano spesso i sistemi di gestione delle relazioni con i clienti (CRM), le piattaforme di posta elettronica e i sistemi di elaborazione degli ordini. Backup incrementali frequenti — ogni 15-60 minuti — contribuiscono a mantenere la perdita di dati entro limiti accettabili. Il costo è moderato e l’impatto aziendale derivante dalla perdita di alcune ore di aggiornamenti della posta elettronica o del CRM è generalmente gestibile tramite il reinserimento manuale dei dati.

Livello 2: da 4 a 12 ore: gli strumenti di collaborazione interna, gli ambienti di sviluppo e le piattaforme di gestione dei progetti operano solitamente in questo intervallo. I backup programmati ogni 4-6 ore consentono di trovare un equilibrio tra protezione e costi di archiviazione.

Livello 3: 12–24 ore: gli archivi di analisi di marketing, i registri storici e la documentazione di riferimento spesso consentono di effettuare backup giornalieri su cloud. I dati cambiano lentamente ed è possibile ricostruirli, rendendo le cadenze di backup giornaliere economicamente vantaggiose.

La suddivisione in livelli aiuta le organizzazioni a concentrare al massimo gli investimenti sulla protezione dei carichi di lavoro in cui ogni minuto di perdita di dati comporta un costo elevato, evitando al contempo spese eccessive per gli archivi che vengono aggiornati solo una volta alla settimana.

RPO e resilienza informatica

Al ransomware non interessa la tua pianificazione dei backup  –, ma è il tuo RPO a determinare il margine di manovra degli aggressori. Un RPO ristretto significa che tra l’ultimo backup immutabile e l’evento di crittografia si trovano meno dati, contribuendo così a ridurre la portata di un attacco.

La resilienza informatica non dipende solo dalla frequenza dei backup. Le copie di backup immutabili e isolate fisicamente aiutano a proteggersi dagli aggressori che compromettono gli ambienti di produzione, impedendo loro di accedere o alterare i dati di Recovery. Quando tali backup vengono archiviati al di fuori dell’account cloud principale, si aggiunge un livello di isolamento che il ransomware non è in grado di superare.

È qui che Clumio di Commvault si inserisce nella vostra strategia RPO. ConClumio, i dati di backup vengono archiviati in un ambiente isolato e completamente gestito, esterno al proprio account AWS principale. Il ripristino granulare a un punto nel tempo consente di tornare a un momento preciso precedente all’attacco — contribuendo a ridurre al minimo la perdita di dati entro l’RPO definito. Progettato per aiutare a mantenere il controllo sul ripristino senza dipendere dalla stessa infrastruttura compromessa dall’autore dell’attacco.

Le organizzazioni che mantengono RPO rigorosi con backup immutabili e isolati possono evitare di pagare il riscatto, poiché sono in grado di ripristinare autonomamente dati integri.

La formula è semplice: un RPO più rigoroso, unito a backup immutabili e isolati, si traduce in genere in una superficie di attacco più ridotta e in un Recovery più rapido e pulito. Questo è il fondamento della resilienza informatica.