L'obiettivo RTO (Recovery Time Objective) definisce il tempo massimo consentito per il ripristino di un servizio. Ad esempio, un database di risorse umane potrebbe avere un RTO di 24 ore perché, sebbene sarebbe molto scomodo perdere l'accesso a questi dati durante la giornata lavorativa, l'azienda può comunque operare. Al contrario, un database che supporta la contabilità generale di una banca avrebbe un RTO misurato in minuti o anche secondi. Un RTO di zero non è possibile, perché deve esserci un modo per distinguere tra un'effettiva interruzione del servizio e un evento di routine, come un pacchetto di rete perso. Tuttavia, un RTO prossimo allo zero è un requisito tipico.

Il recovery point objective (RPO) definisce la massima perdita di dati tollerabile. In molti casi, l'RPO è determinato unicamente dalla frequenza delle snapshot o degli aggiornamenti di snapmirror.

In alcuni casi, l'RPO può essere reso più aggressivo proteggendo determinati dati con maggiore frequenza. In un contesto di database, l'RPO è in genere una questione di quanti dati di registro possono essere persi in una situazione specifica. In uno scenario di ripristino tipico in cui un database viene danneggiato a causa di un bug del prodotto o di un errore dell'utente, l'RPO deve essere pari a zero, il che significa che non ci devono essere perdite di dati. La procedura di ripristino prevede il ripristino di una copia precedente dei file di database e la riproduzione dei file di registro per portare lo stato del database al momento desiderato. I file di registro necessari per questa operazione dovrebbero essere già presenti nella posizione originale.

In scenari insoliti, i dati del registro potrebbero andare persi. Ad esempio, un accidentale o dannoso rm -rf * di file di database potrebbe causare l'eliminazione di tutti i dati. L'unica opzione sarebbe il ripristino dal backup, inclusi i file di registro, e alcuni dati andrebbero inevitabilmente persi. L'unica opzione per migliorare gli RPO in un ambiente di backup tradizionale sarebbe l'esecuzione di backup ripetuti dei dati di log. Questo comporta dei limiti, tuttavia, a causa dello spostamento costante dei dati e della difficoltà di mantenere un sistema di backup come servizio in esecuzione costante. Uno dei benefici dei sistemi storage avanzati è la capacità di proteggere i dati da danni accidentali o dannosi ai file e garantire quindi un RPO migliore senza spostamento dei dati.

Il ripristino di emergenza include l'architettura IT, i criteri e le procedure necessarie per il ripristino di un servizio in caso di emergenza fisica. Tra questi, inondazioni, incendi o persone che agiscono con intento doloso o negligente.

Il disaster recovery non è solo una serie di procedure di ripristino. Si tratta del processo completo di identificazione dei vari rischi, definizione dei requisiti di ripristino dei dati e continuità del servizio e realizzazione della giusta architettura con le relative procedure.

Durante la definizione dei requisiti di protezione dei dati, è fondamentale differenziare tra i requisiti tipici di RPO e RTO e quelli di RPO e RTO necessari per il disaster recovery. Alcuni ambienti applicativi richiedono un RPO pari a zero e un RTO prossimo allo zero per situazioni di perdita di dati che vanno da errori utente relativamente normali a incendi che distruggono un data center. Tuttavia, vi sono conseguenze amministrative e di costo per questi elevati livelli di protezione.

In generale, i requisiti di ripristino dei dati non di emergenza devono essere rigorosi per due motivi. Innanzitutto, i bug applicativi e gli errori degli utenti che danneggiano i dati sono prevedibili al punto che sono quasi inevitabili. In secondo luogo, non è difficile progettare una strategia di backup in grado di offrire un RPO pari a zero e un RTO basso finché il sistema storage non viene distrutto. Non c'è motivo di non affrontare un rischio significativo che sia facilmente risolvibile, motivo per cui gli obiettivi di RPO e RTO per il ripristino locale dovrebbero essere aggressivi.

I requisiti di RTO e RPO per il disaster recovery variano in modo più ampio in base alla probabilità di un disastro e alle conseguenze della perdita di dati associata o dell'interruzione di un business. I requisiti di RPO e RTO devono essere basati sulle effettive esigenze di business e non su principi generali. Devono tenere conto di più scenari di emergenza logici e fisici.

L'ultimo aspetto di una strategia di protezione dei dati è il tempo di conservazione dei dati, che può variare drasticamente.