La vera differenza fra RTO e RPO (Recovery Time VS Point Objective) nell’infrastruttura di backup e come garantire il migliore recupero dei dati aziendali

Il recovery point objective (RPO) e il recovery time objective (RTO) sono due parametri molto specifici strettamente associati con le attività di ripristino e più in generale con la tipologia di infrastruttura di backup dei dati.

Il significato di RTO e RPO in informatica

L’obiettivo del punto di ripristino (RPO) e l’obiettivo del tempo di ripristino (RTO) rappresentano i due parametri più importanti di un piano di ripristino di emergenza o di protezione dei dati.

Questi due parametri solitamente sono scelti dalle aziende per stabilire, all’interno di un piano di backup e ripristino, quanti e quali dati si vogliono salvare nel caso di una emergenza.

Che cos’è il Recovery Time Objective (RTO)

Il Recovery Time Objective (RTO) è il tempo che occorre per il totale recupero dell’operatività di un sistema o di un processo organizzativo in Business Critical System (quale per esempio nella fattispecie implementazioni di politiche di Disaster recovery nei Sistemi Informativi). In pratica si tratta, della massima durata tollerata o prevista del downtime.

È fondamentale il fatto che il valore di RTO venga definito, conosciuto e verificato. Serve tener presente che naturalmente un downtime più lungo danneggia la possibilità di fruire dell’applicazione o servizio. Ma il pericolo maggiore deriva dall’inconsapevolezza di quanto possa essere il tempo previsto per il ripristino dei servizi danneggiati.

Che cos’è il Recovery Point Objective (RPO)

Il Recovery Point Objective (RPO) è uno dei criteri usati nell’ambito delle policy di disaster recovery per descrivere quale possa essere la tolleranza ai guasti di un sistema informatico. Esso rappresenta il massimo tempo che deve intercorrere tra la produzione di un dato e la sua messa in sicurezza (per esempio attraverso backup). E, di conseguenza, offre la misura della massima quantità di dati che il sistema può perdere a causa di guasto improvviso.

Quanto più diminuisce l’RPO desiderato/specificato tanto più si rendono necessarie politiche di sicurezza assai stringenti e dispendiose, che possono andare dal salvataggio dei dati su supporti ridondanti che possano essere ridondanti fino alla loro quasi immediata replicazione su un sistema informatico secondario d’emergenza (soluzione, in linea teorica, capace di garantire valori di RPO prossimi allo zero).

RTO e RPO, le differenze spiegate con esempi

Il parametro RTO è realmente usato per prescrivere l’utilizzo della replicazione o del backup su nastro o disco. Ciò stabilisce anche cosa metterete assieme per un’infrastruttura. E questo sia che si tratti di un cluster ad alta disponibilità per il failover senza soluzione di continuità, o di qualcosa di più modesto.

Se il vostro Recovery Time Objective (RTO) è zero (non è possibile avere interruzioni) allora potete optare per un’infrastruttura completamente ridondante con dati replicati fuori sede e così via. Se il vostro RTO è 48 ore o 72 ore, allora forse il backup su nastro è OK per quella specifica applicazione. Questo è l’RTO. Ora vediamo le differenze tra RTO e RPO.

La perdita di dati ammissibili

Il parametro RPO è leggermente differente. Da qui la differenza rpo/rto. Questo disciplina la perdita di dati ammissibile – ossia quanti dati mi posso permettere di perdere?

In altre parole, se faccio un backup serale alle 7pm e il mio sistema va in fiamme alle 4pm del giorno seguente, tutto ciò che è stato cambiato dal mio ultimo backup è perduto. Il mio RPO in questo particolare contesto è il backup del giorno precedente. Se sono un’azienda che fa elaborazione di transazioni online (per esempio American Express) bene forse il mio Recovery Point Objective (RPO) risale fino all’ultima, recentissima transazione. E cioè fino agli ultimi bit d’informazione che sono entrati. Di nuovo, ciò indica il tipo di soluzione di protezione dati che volete mettere in atto.

Quindi entrambi i parametri, RTO e RPO, effettivamente influenzano il tipo di ridondanza o di infrastruttura di backup che metterete assieme. Più ristretti sono l’RTO e l’RPO, più denaro spenderete sulla vostra infrastruttura.

Disaster recovery e RTO/RPO

Come è evidente nella dettagliata spiegazione di che cosa sono RTO e RPO, queste due metriche rappresentano fattori di importanza determinante nel più ampio discorso del disaster recovery. Esse servono per assicurare efficienza dei servizi aziendali. Siano essi rivolti agli utenti interni o agli interlocutori esterni così come al ripristino dei sistemi IT nel loro complesso.

Significato di Disaster recovery

Con Disaster recovery (spesso abbreviato DR) in informatica si intende, tutto l’insieme di misure tecnologiche e organizzativo/logistiche che servono per fare il ripristino dei sistemi. E più nello specifico per tutelare le infrastrutture, il patrimonio di dati eccetera. Tutto ciò che serve per erogare i servizi nel momento in cui si è dovuto far fronte ad attacchi alla sicurezza informatica, situazioni di emergenze e così via che impediscono la normale attività.

Il piano di continuità

Ogni azienda per riuscire nell’intento di rispondere a queste eventualità con prontezza deve redigere il proprio Disaster recovery plan (il piano di recupero del disastro). Si tratta del documento che riporta nel dettaglio le misure da adottare e include il suo piano di continuità operativa. Tale documento è teso a raggruppare le procedure che guidano le organizzazioni nella loro risposta e ripresa delle attività in seguito di una interruzione.

Il piano elenca tutte le varie risorse, i servizi e le attività che servono per avere continuità delle funzioni organizzative più critiche. Ovviamente i piani sono diversi tra loro a seconda della complessità dell’organizzazione, delle sue dimensioni. Per una grande realtà articolata su più territori, per esempio, potrebbero servire più piani strutturati che riguardino i prodotti, le applicazioni oppure le sedi, oppure ancora le divisioni e i dipartimenti.

Il piano di continuità operativa può addirittura arrivare a includere programmi specifici che includano processi e informazioni specifiche che devono essere trattate separatamente. Possiamo pensare a piani di crisi, piani pandemici, piano di comunicazione nella crisi e via di questo passo.

In generale, il piano di continuità operativa ha vari obiettivi. Si intende da quelli strategici per la gestione di problematiche di varia natura (incluso per esempio i rischi di veder minata la reputazione in seguito a sottrazione di dati sensibili), a quelli più tattici (come abbiamo visto più sopra per garantire la continuità operativa) a quelli più operativi per delineare i passaggi che vanno compiuti dai team incaricati di far fronte alle emergenze.