In uno dei miei blog precedenti , ti ho presentato il concetto sia del tuo obiettivo di recupero (RTO) che del tuo obiettivo del punto di ripristino (RPO). Sono due concetti importanti che definiscono per quanto tempo è necessario eseguire un ripristino e solo quanto i dati persi sono accettabili:

  • RTO (Recovery Time Objective): quanto tempo per tornare operativi?
    Il concetto di RTO invece si riferisce al tempo che intercorre tra il disastro e il completo ripristino dei sistemi. Ad esempio, se non posso permettermi neanche un minuto di disservizio, il mio RTO sarà zero.

  • RPO (Recovery Point Objective): quanti dati posso permettermi di perdere?
    RPO è la metrica che indica il tempo trascorso dall’ultima replica fino all’accadere del disastro. Ovviamente è legato alla frequenza di replica dei sistemi, più è frequente meno sarà l’eventuale perdita massima di dati.

A seconda del valore che viene attribuito a questi parametri si sceglierà una soluzione di Disaster Recovery diversa, in modo da rispettare le tempistiche e gli obiettivi definiti nel piano di azione.

​​Per le applicazioni di livello 1 critiche, la regola generale è di 15 minuti ciascuna. Con tutta la tecnologia disponibile oggi – come la replica continua in un ambiente virtuale esterno – non è più roba da sogni; è una realtà.

Ma nessun tuo cliente ha lo stesso livello di aspettativa, né lo stesso budget di servizio disponibile. Quindi, mentre 15 minuti suona davvero bene, potrebbe non essere realistico.

Quindi, come si calcola quale dovrebbe essere il giusto RTO e RPO?

Vorrei iniziare aggiungendo un nuovo acronimo – il MTPD (periodo di interruzione massimo tollerabile). Rappresenta fondamentalmente quanto a lungo finché il tuo cliente non si arrabbia!

Ora, come RTO e RPO, questo non sarà lo stesso per ogni applicazione e servizio che gestisci per loro. In effetti, è meglio per te dal punto di vista dei servizi, se non lo fai.

(Perché? Perché avere diversi SLA per varie applicazioni in un cliente ti consente di addebitare tariffe diverse, con un aumento delle entrate dei servizi!)

Che cos’è MTPD e dove si adatta?

Quindi, inizierei definendo il MTPD corretto partendo da una base relativa per applicazione con il cliente. Diciamo per esempio che per una determinata applicazione, è 1 ora. OK, bene, allora sai che RTO e RPO non possono essere più di un’ora. Quello che abbiamo fatto usando il MTPD è stabilire il limite massimo, fornendoti alcune indicazioni su dove devono essere i valori per mantenere in funzione l’attività dei tuoi clienti.

Successivamente, devi capire le limitazioni fisiche relative ai set di dati specifici che dovranno essere ripristinati legati ai metodi di backup correnti utilizzati.

Ecco cosa intendo: se hai un enorme database SQL – come un paio di TBs di dimensioni – e stai attualmente facendo un backup a livello di file di quel database (perché il tuo cliente non ha ancora investito in un ambiente virtuale offsite) , devi fare i calcoli su quanto tempo ci vorrà per recuperare quei dati (l’RTO) e quanto indietro nel tempo i dati saranno recuperati una volta (l’RPO).

Ora, rimetti in gioco il MTPD – stai bene?

Molto probabilmente, dovrai avere una conversazione con il cliente sulla modifica del loro metodo di backup (e ripristino) in modo che tu possa trovare un RTO / RPO che soddisfi le esigenze del cliente.

Questo processo deve essere ripetuto per ogni set di dati, applicazione e sistema importanti per il cliente.

In realtà, non vi è alcun RTO / RPO impostato che dovresti incontrare, diverso da quello nella mente del cliente. Ecco perché elevare la conversazione alla comprensione di quale sia il loro MTPD, può aiutarti a calcolare meglio un RTO e un RPO che soddisfano le loro esigenze o creare una nuova strategia di recupero.