Descrivere gli obiettivi del tempo di ripristino e del punto di ripristino
Comprendere il significato degli obiettivi del tempo di ripristino e del punto di ripristino è fondamentale per definire un piano per la disponibilità elevata e il ripristino di emergenza (HADR), poiché questi valori sono alla base di qualsiasi soluzione di disponibilità.
Obiettivo tempo di ripristino
L'obiettivo del tempo di ripristino (RTO, Recovery Time Objective) è la quantità massima di tempo disponibile per portare online le risorse dopo un'interruzione o un problema. Se il processo richiede più tempo rispetto all'RTO, possono verificarsi conseguenze negative quali sanzioni finanziarie, impossibilità di portare a termine il lavoro e così via. È possibile specificare l'RTO per l'intera soluzione, che include tutte le risorse, e per i singoli componenti, ad esempio database e istanze di SQL Server.
Obiettivo del punto di ripristino
L'obiettivo del punto di ripristino (RPO, Recovery Point Objective) è il punto nel tempo fino al quale è necessario ripristinare un database e corrisponde alla quantità massima di perdita di dati che l'azienda è disposta ad accettare. Si supponga, ad esempio, che in una macchina virtuale IaaS contenente SQL Server si verifichi un'interruzione alle ore 10.00 e che i database all'interno dell'istanza di SQL Server abbiano un RPO di 15 minuti. Indipendentemente dalla funzionalità o dalla tecnologia usata per ripristinare l'istanza e i relativi database, ci si aspetta che si verifichi una perdita di dati per un tempo non superiore a 15 minuti. Ciò significa che il database può essere ripristinato fino alle ore 9.45 o più tardi, per assicurarsi che non si verifichino perdite di dati o che queste siano minime, in conformità all'RPO dichiarato. Possono essere presenti fattori che determinano se tale RPO è realizzabile.
Definizione degli obiettivi del tempo di ripristino e del punto di ripristino
I valori di RTO e RPO sono determinati dai requisiti aziendali, ma dipendono anche da vari fattori tecnologici e di altro tipo, ad esempio dalle competenze e dalle capacità degli amministratori (non solo gli amministratori di database). Anche se un'azienda può non volere che si verifichino tempi di inattività o perdite di dati, questa ipotesi potrebbe risultare irrealistica o impossibile per diversi motivi. La determinazione dell'RTO e dell'RPO di una soluzione deve essere il risultato di una discussione aperta e onesta tra tutte le parti coinvolte.
A tale proposito, uno degli aspetti cruciali da tenere presenti è il costo del tempo di inattività. Se si definisce tale numero e l'effetto complessivo che può avere lo stato di inattività o non disponibilità per l'azienda, è più facile definire le soluzioni appropriate. Ad esempio, se l'azienda può perdere 10.000 all'ora o rischia una sanzione da parte di un ente amministrativo se alcuni dati non sono stati elaborati, questi fattori rappresentano un metodo misurabile per aiutare a definire l'RTO e l'RPO. La spesa per la soluzione deve essere proporzionale alla quantità, o al costo, del tempo di inattività. Se la soluzione HADR costa X USD, ma consente di limitare il danno a pochi secondi, anziché a ore o a giorni, nel caso di un problema, la spesa è perfettamente giustificata.
Da un punto di vista non commerciale, l'RTO deve essere definito a livello di componente (ad esempio SQL Server) e anche per l'intera architettura dell'applicazione. La possibilità di eseguire il ripristino in seguito a un'interruzione è quantificabile solo in base al suo anello più debole. Se, ad esempio, SQL Server e i relativi database possono essere portati online in cinque minuti, ma i server applicazioni richiedono 20 minuti per eseguire la stessa operazione, l'RTO complessivo sarà di 20 minuti e non di cinque. L'ambiente di SQL Server avrà pure un RTO di cinque minuti, ma questo non cambia la quantità di tempo complessiva necessaria per il ripristino.
L'RPO riguarda in modo specifico i dati e influisce direttamente sulla progettazione di qualsiasi soluzione HADR, oltre che sulle procedure e sui criteri di amministrazione. Le funzionalità usate devono supportare sia l'RTO che gli RPO definiti. Se, ad esempio, i backup del log delle transazioni vengono pianificati ogni 30 minuti, ma è definito un obiettivo del punto di ripristino di 15 minuti, un database potrebbe essere ripristinato solo in base all'ultimo backup del log delle transazioni disponibile, che nel peggiore dei casi sarebbe avvenuto 30 minuti fa. Questa tempistica presuppone che non vi siano altri problemi e che i backup siano stati testati e siano risultati validi. Se da un lato è difficile testare ogni backup generato per ogni database nell'ambiente in uso, dall'altro bisogna considerare che i backup sono semplicemente file all'interno di un file system. Senza eseguire almeno periodicamente operazioni di ripristino, non c'è alcuna garanzia che i backup siano validi. L'esecuzione di controlli durante il processo di backup può garantire un certo livello di affidabilità.
Anche le specifiche funzionalità usate, come un gruppo di disponibilità Always On o un'istanza del cluster di failover Always On, possono avere effetto sui valori di RTO e RPO. A seconda di come sono configurate le funzionalità, le soluzioni IaaS o PaaS possono o meno effettuare automaticamente il failover in un'altra posizione, con conseguenti tempi di inattività più lunghi. Se si definiscono l'RTO e l'RPO, la soluzione tecnica che supporta tale requisito può essere progettata sulla base dei margini di perdita di tempo e dati. Se questi non risultano realistici, i valori di RTO e RPO devono essere modificati di conseguenza. Se, ad esempio, si definisce un RTO di due ore, ma un backup impiega tre ore per copiare i dati di ripristino nel server di destinazione, l'RTO non risulta soddisfatto. È necessario tenere conto di questi tipi di fattori nel determinare i valori di RTO e RPO.
I valori di RTO e RPO dovrebbero essere definiti sia per la disponibilità elevata sia per il ripristino di emergenza. La disponibilità elevata è considerata un evento più localizzato, che offre maggiori possibilità di ripristino. Un esempio di disponibilità elevata è dato dal failover automatico di un gruppo di disponibilità da una replica a un'altra all'interno di un'area di Azure. Il processo può richiedere alcuni secondi e, a quel punto, è necessario assicurarsi che l'applicazione riesca a connettersi dopo il failover. Il tempo di inattività di SQL Server sarebbe minimo. Un RTO o RPO locale può essere misurato in minuti, a seconda della natura critica della soluzione o del sistema.
Il ripristino di emergenza può invece essere paragonato all'attivazione di un nuovo data center. Ci sono molte tessere del puzzle da ricomporre e SQL Server è solo uno dei vari componenti. Riportare tutti i componenti online può richiedere ore o addirittura un tempo più lungo. Ecco perché i valori di RTO e RPO vengono considerati separatamente. Anche se molte delle tecnologie e delle funzionalità usate per la disponibilità elevata e il ripristino di emergenza sono le stesse, il livello di impegno e tempo richiesto potrebbe non essere uguale.
Tutti i valori di RTO e RPO devono essere documentati in modo formale e rivisti periodicamente, o comunque in base alle esigenze. Una volta documentati questi valori, è possibile prendere in considerazione le tecnologie e le funzionalità che possono essere usate per l'architettura.