RPO e RTO sono due parametri temporali fondamentali da fissare in ogni piano di Business Continuity, il quale deve prevedere politiche per il salvataggio e il recupero dei dati, ma anche stabilire principi chiari riguardo eventuali perdite tollerabili di dati e tempi certi di ripristino.

Tecnicamente, Recovery Point Objective (RPO) e Recovery Time Objective (RTO) sono entrambi elementi da fissare per indicare i tempi in cui si verificano determinate condizioni. RPO o Punto di Recupero indica quante ore/giorni di dati possiamo permetterci di perdere in caso di un incidente, quindi quanto indietro nel tempo bisogna tornare, dal momento del crash, per trovare un backup valido. RTO o Tempo di Recupero, invece, rappresenta il tempo stimato per il ritorno alla normalità, ovvero quanto tempo dopo una perdita di dati il sistema sarà di nuovo online. Questi due punti, se messi su una retta temporale con al centro il momento dell’incidente, mostreranno che l’RPO si riferisce al passato e l’RTO al futuro: l’obiettivo del CIO e dei tecnici sarà quello di avvicinare il più possibile questi due punti al momento del disastro, fino a farli (teoricamente) coincidere.

Cosa impedisce di realizzare questo obiettivo ideale, ovvero avere un sistema informativo che in caso di crash non perda dati e non presenti tempi di non-disponibilità? Dal punto di vista tecnico, nulla. Esistono varie tipologie di sistemi che realizzano questo risultato. Il problema, in realtà, è legato ai costi: una soluzione con tempi di RPO e RTO pari a zero è, tipicamente, piuttosto costosa. Tuttavia, senza investire cifre abnormi, è possibile realizzare sistemi informativi con tempi di RPO e RTO molto bassi.

Incidenti differenti, contromisure differenti

Naturalmente, bisogna considerare da quale tipo di incidente voglio proteggere il sistema. Se il mio obiettivo è proteggermi dalla perdita di dati generata da un crash hardware (un disco che si guasta, l’alimentatore di uno storage che va in corto circuito), probabilmente basterebbe adottare uno storage RAID “mirrorato” per avere perdita di dati e tempo di ripristino pari a zero: in questo caso si spenderebbe il doppio in dischi, ma si escluderebbero spese supplementari. Ciò, supponendo di tenere entrambe le copie dei dati nello stesso luogo fisico, soluzione che protegge dal guasto hardware ma non, per esempio, da incidenti come un incendio. Per avere anche una protezione di questo tipo, la seconda copia online dei dati deve essere in un altro edificio – o almeno in un’altra stanza – collegata all’archivio principale con una connessione molto veloce; ciò comporterebbe però una crescita dei costi.

Altra casistica differente, riguarda la protezione da errori software (delle applicazioni, del sistema operativo) o da errori umani commessi di tanto in tanto da operatori e/o utenti (per esempio un file cancellato per distrazione, o dei file criptati da un ransomware). Per quest’ultimo caso, avrò bisogno probabilmente di una grande quantità di storage dove conservare near-on-line una serie di backup da cui eseguire il restore, oppure un certo numero di “snapshot” o repliche del sistema. Questo numero cambierà in base a quanto voglio che la protezione possa andare indietro nel tempo e alla frequenza con cui eseguo le snapshot: se esse risulteranno molto ravvicinate, potrò risalire fino a un punto molto vicino (e precedente) a quello dell’errore; se le eseguo a distanza di varie ore (o giorni) il mio punto di ripristino sarà probabilmente molto lontano da quello dell’errore, sarà quindi necessaria una certa quantità di lavoro per ricostruire il resto del database.

Avrò poi bisogno di un sistema software di gestione che mi permetta di tornare indietro nel tempo fino a prima che l’errore venisse commesso.

Ridurre i tempi di RPO e RTO

Molto spesso le organizzazioni devono rispondere a tutte queste esigenze ma farlo con prodotti diversi su architetture differenti, non solo è estremamente complicato, ma è anche sconsigliabile.

Una soluzione valida e “unificata” è data dall’uso di un software di backup che sia in grado di fornire anche le funzionalità di replica dei dati, sullo stesso sistema informativo. Le configurazioni richieste sono naturalmente diverse questo perché, mentre per il backup/restore è richiesta solo la presenza di apparati di storage, per la replica dobbiamo avere un server che garantisca la potenza di calcolo necessaria a far ripartire il sistema. Un sistema di protezione di questa tipologia consente di ridurre anche significativamente i tempi di RPO/RTO con una spesa contenuta, in parte anche grazie all’elevata velocità nel trasferire i dati. I tempi, comunque, non saranno azzerati perché dipendono da quando è stato fatto l’ultimo backup o l’ultima replica. Se il backup risale a pochi minuti prima dell’incidente, il recupero totale avverrà in pochissimo tempo, mentre se l’errore è avvenuto per esempio la sera e il backup risale alla notte precedente, i tempi si allungheranno significativamente. Naturalmente, se aumento la quantità di storage da dedicare alla conservazione dei backup/repliche, ottengo di poter mantenere un maggior numero di copie, quindi posso avere in memoria backup più vecchi, oppure eseguirne e memorizzarne più frequentemente, aumentando quindi la granularità e migliorando le prestazioni e l’RTO. Una soluzione di questo tipo, che può essere messa in opera anche solo con pochi elementi – per esempio in una tipica installazione virtualizzata basta un solo storage (con la sua ridondanza interna) e il software di backup – è ideale per piccole e piccolissime aziende e in caso di incidente può ottenere tempi di ripristino di qualche ora.

Soluzioni Iperconvergenti e SDS

Ma se azzerare, o quasi, i tempi di recupero è fondamentale, la modalità migliore è scegliere tra soluzioni Iperconvergenti e SDS (Software Defined Storage). Quest’ultima può essere costituita, per esempio, da due server industry standard, sui quali gira Windows Server 2019, con l’attivazione di questo sistema. Le due macchine, viste dal software come sistemi storage, sono equipaggiate con normali dischi JBOD (niente hardware proprietario o dedicato). Grazie a questa soluzione, i due hardware si “mirrorano” in tempo reale, fornendo la protezione dai guasti ai dischi con tempi di recupero (RPO/RTO) pari a zero. Se invece abbiamo un incidente software o da errore umano, il tempo di RPO è pari al tempo di trovare il dato integro, mentre il tempo di RTO varia a seconda di quanto il dato salvato è distante dal momento nel quale è avvenuto l’incidente. Le prestazioni del sistema saranno nel complesso migliori, a un costo però leggermente più alto.

Come al solito, la scelta di quale tecnologia impiegare, dipenderà dalle reali necessità aziendali in termini di possibilità di tollerare dei fermi di sistema non programmati e di perdite reali provocate dalla necessità di reintrodurre eventuali dati persi.