Backup, DR e business continuity

RTO e RPO: cosa sono e come calcolarli

14 Maggio 2015
Il tuo ufficio è andato a fuoco durante il weekend. Ci spiace darti questa cattiva notizia, ma purtroppo è la realtà.
Cosa farà adesso la tua azienda? Quanto rapidamente potrai far tornare operativa la tua infrastruttura IT? Quali dati devono essere ripristinati prioritariamente?
Queste sono le domande da porsi quando bisogna definire un piano di disaster recovery.

Nel settore queste domande sono note come RTO (Recovery Time Objective) e RPO (Recovery Point Objective).
Ma come si determina il valore RTO/RPO ideale per un'azienda?

In questo articolo spiegheremo i concetti di RTO/RPO e vedremo come applicarli in modo da rendere l'infrastruttura IT della tua azienda davvero a prova di bomba.
 


In questo modo anche se ti dovesse mai capitare di scoprire che i tuoi sistemi e i tuoi dati sono finiti in cenere (o, meno tragicamente, che il tuo server è andato in crash), la tua prima reazione non sarà quella di chiederti sconsolato: "E adesso?".
RTO/Recovery Time Objective
Il tuo RTO si riferisce a quanto tempo la tua azienda può permettersi di restare con i propri sistemi essenziali offline prima che il blocco abbia ripercussioni sull'attività. In termini ancora più semplici è la risposta alla domanda: in quanto tempo può essere completato il ripristino?
Quando si determina un RTO accettabile occorre concentrarsi sulle singole applicazioni piuttosto che su interi server. Il cronometro inizia a misurare l'RTO nel momento in cui un'applicazione essenziale smette di funzionare, e non si ferma fino a quando essa non torni a essere riutilizzabile da parte di tutti coloro che possono averne bisogno.

RPO/Recovery Point Objective

 
Anziché al tempo di ripristino, RPO si riferisce ai sistemi e alle applicazioni. Determinare l'RPO significa calcolare quanta parte dei dati contenuti all'interno di questi sistemi e applicazioni l'azienda possa permettersi di perdere.
In altre parole, se puoi permetterti di perdere due ore di dati di Exchange Server senza che questo comporti conseguenze pesanti sull'attività della tua azienda, allora il tuo RPO sarà di due ore.
Mentre l'RTO determina la velocità necessaria per il ripristino, l'RPO determina la frequenza con la quale dovresti effettuare i backup e quale tipologia di backup è necessaria.
L'RPO è importante per i backup dal momento che affronta la questione del quando e del quanto spesso occorre eseguirli.
Se si effettua un backup alle 9 di sera e alle 10 della mattina successiva si perde un hard disk con tutti i suoi dati, ecco che potrebbero esserci fino a dodici ore di dati perduti – quello che si chiama “gap di backup”.
In pratica i dati perduti potrebbero essere solamente messaggi email e documenti Word creati dai dipendenti che si trovavano in ufficio dalle 8 alle 10 di quella mattinata; oppure potrebbero essere dodici ore continue di dati di un database aggiornato costantemente tutta la notte da un'importante applicazione…

Il segreto è quello di capire quali dati si perderebbero su ciascun sistema in caso di guasto, e quanti di essi ci si possa permettere (eventualmente) di perdere.


Bene, adesso che i concetti di RTO/RPO sono chiari possiamo mettere in pratica quanto abbiamo imparato sinora.

Determinare il downtime
Quando si stabilisce un livello accettabile di downtime (per la precisione stiamo parlando della componente RTO della pianificazione RTO/RPO) si può essere tentati di chiedere semplicemente informazioni agli utenti. Dopotutto sono loro che sanno quanto a lungo possono fare a meno delle loro applicazioni, no? Ebbene, forse non è così.

Sei un fornitore IT e vuoi sapere come trasformare il downtime dei clienti in ricavi ricorrenti? Dai un'occhiata a questo articolo.

In generale, quando si pone la domanda agli utenti finali si ottiene una risposta che può essere irrealisticamente breve ("Se non posso accedere alla posta per trenta secondi perdo le vendite e il mondo così come lo conosciamo cessa di esistere") o ingenuamente lunga ("Non so nemmeno cosa faccia quell'applicazione, quindi immagino di poterne fare a meno per qualche mese").
Ecco perché, come per la maggior parte dei casi della vita, occorre trovare la risposta nei dati oggettivi.
E ci sono due passi da compiere.
  1. Stilare un elenco completo di tutti i sistemi e di tutte le applicazioni di cui l'azienda si avvale per la propria attività; dopodiché occorre determinare il ruolo ricoperto da ciascuno di questi elementi, ovvero le funzioni svolte e gli uffici/utenti coinvolti da un potenziale blocco.
  2. Calcolare le perdite che potrebbero potenzialmente verificarsi qualora il sistema o l'applicazione fossero indisponibili: perdite di fatturato o vendite, stipendi pagati a dipendenti inattivi, spese aggiuntive causate dalla mancanza di accesso, danni alla reputazione aziendale… Questo calcolo va fatto individualmente per ogni singola applicazione senza dimenticare di considerare le stagionalità dal momento che in alcuni periodi dell'anno le conseguenze possono essere notevolmente più pesanti rispetto ad altri.
Una volta definiti questi dettagli inizia il vero divertimento: quello di determinare esattamente quanto tempo possa trascorrere prima che queste perdite diventino inaccettabili.
Per quanto il valore preciso dipenda dalle caratteristiche specifiche del business, vi sono alcune domande che possono aiutarti a perfezionare il tuo RTO ideale:
  • conservi dati per conto dei tuoi clienti? Nel caso, quali sono gli accordi e gli obblighi correlati a questo servizio? Questo elemento può influire sulla rapidità necessaria per il ripristino di quei dati.
  • Hai clienti che devono poter accedere ai tuoi dati in tempo reale? Un esempio potrebbe essere quello dei sistemi point-of-sale.
  • Quali sistemi sono legati a dipendenze? Per esempio, nel caso di perdita di un database, quali applicazioni ne sarebbero colpite e quali sono i corrispondenti requisiti di uptime?
  • Quali sistemi causerebbero perdite finanziarie dirette in caso di indisponibilità? Per esempio un sito e-commerce.
  • Quali sistemi causerebbero un blocco della produzione in caso di indisponibilità? Per esempio sistemi di controllo qualità o di controllo industriale.
Una volta risposto a tutte queste domande e calcolati i tempi di ripristino di ogni applicazione e ogni sistema, il tuo RTO complessivo viene determinato in uno dei seguenti modi: o esiste un'applicazione che può causare danni e perdite ben superiori rispetto alle altre, e allora l'RTO è il tempo necessario a ripristinare questa applicazione; oppure se tutte le applicazioni hanno un'incidenza simile sul business è sufficiente calcolarne la media matematica e usarla come RTO.
 
Il passo finale è quello di eseguire un test di ripristino di tutti i sistemi e di tutte le applicazioni. Il tempo richiesto da questa procedura si chiama RTA (Recovery Time Actual), e il tuo obiettivo è di fare in modo che RTO e RTA si equivalgano.
Decidere cosa recuperare
La fase finale della pianificazione RTO/RPO riguarda la determinazione del livello accettabile di perdita di dati. L'RPO si riferisce spesso alla frequenza con cui i dati sono ripristinabili; ovvero, in caso di backup quotidiani il punto di ripristino sarà di 24 ore.
Sebbene sia possibile ottenere un RPO senza perdite di dati, le soluzioni necessarie allo scopo sono quasi sempre costose. La maggior parte delle aziende deve determinare un RPO realistico capace di causare l'impatto minimo possibile.
Ricordi le domande che ti eri posto quando hai dovuto calcolare l'RTO? Ebbene, le stesse considerazioni riguardano anche l'RPO, con la differenza che il punto focale è rappresentato dai dati anziché dal tempo.
Una volta quantificati i dati che puoi permetterti di perdere, puoi pianificare una strategia di backup allineata ai requisiti di ogni sistema, data store e applicazione.
Un backup quotidiano ti permetterà di mantenere una copia dei dati fotografati al termine della giornata lavorativa precedente. Se hai determinato che una perdita di dati che dovesse avvenire in un qualsiasi momento della giornata possa essere neutralizzata dal backup del giorno prima, allora puoi proteggere i tuoi dati con un backup quotidiano.
Se invece hai determinato di non poter perdere altro che qualche ora di dati, allora un backup quotidiano non è sufficiente; avrai invece bisogno di un backup continuativo dei dati lungo tutto l'arco della giornata. Per un hard disk di dati questo può significare un disco di mirror; per un database SQL può comportare un backup a livello di transazione da effettuare ogni 10-15 minuti.
Se le tue esigenze si trovano invece tra i due estremi e puoi permetterti di perdere mezza giornata di dati, allora potresti considerare di effettuare due backup al giorno.
 
Autore
Claudio Panerai
Gli ultimi prodotti che vi ho portato, nel 2020: Vade Secure Il primo sistema antispam/antihishing/antimalware basato sull'intelligenza artificiale e appositamente progettato per Office 365. Naturalmente a misura di MSP. ID Agent Piaffaforma che consente agli MSP di monitorare le credenziali (proprie e dei clienti) che sono in vendita nel dark web.
Nato a Ivrea nel 1969, è sposato e padre di due figlie. Laureato in Scienze dell’Informazione nel 1993, ha dapprima svolto numerose consulenze e corsi di formazione per varie società per poi diventare responsabile IT per la filiale italiana del più grande editore mondiale di informatica, IDG Communications. Dal 2004 lavora in Achab dapprima come Responsabile del Supporto Tecnico per poi assumere dal 2008 la carica di Direttore Tecnico. Giornalista iscritto all’albo dei pubblicisti, dal 1992 pubblica regolarmente articoli su riviste di informatica e siti web di primo piano. E' stimato da colleghi e clienti per la schiettezza e onestà intellettuale. Passioni: viaggi, lettura, cinema, Formula 1, sviluppo personale, investimenti immobiliari, forex trading. Claudio è anche su LinkedIn e Facebook.
Commenti (0)

Lascia un commento

Il tuo indirizzo e-mail non verrà pubblicato, lo utilizzeremo solamente per inviarti la notifica della pubblicazione del tuo commento. Ti informiamo che tutti i commenti sono soggetti a moderazione da parte del nostro staff.