tempo di lettura: 4 minuti
“Quanto manca?”. Se siete stati bambini (e se state leggendo penso non lo siate più, per cui lo siete stati) o se avete affrontato ancora un viaggio in macchina con dei figli questa è sicuramente una domanda che vi siete sentiti dire molte, molte volte… spesso una di troppo 🙂
I bambini non sanno aspettare, vorrebbero subito arrivare a destinazione, specie se durante il viaggio non hanno niente da fare che giudichino interessante.
La certezza di arrivare alla meta passa in secondo piano rispetto al dover aspettare per raggiungerla.
Ma la stessa domanda la pongono anche gli adulti. Adulti che – spesso – sanno diventare anche più insistenti dei bimbi.
Non vi è mai capitato? Provate allora a stare vicino ad un responsabile IT o ad un imprenditore di una PMI a cui si è rotto il server o che ha “bruciato” per errore il database del gestionale e deve tornare ad essere operativo.
I clienti iniziano a chiamare, i trasportatori sono nel piazzale in attesa della bolla per poter partire con la merce, la responsabile amministrativa inizia a dire che – a questo punto – è meglio andare tutti in ferie, “perché non si può lavorare così…”.
Ecco in queste condizioni la domanda “quanto manca, c***o???” risuonerà dal CED al parcheggio.
Diciamola tutta: potersi fare questa domanda è già una bella cosa perché significa che il backup esiste, è aggiornato ed è iniziata la fase di restore (cioè di ripristino dei dati) e questo, come dicono oggi “è già tanta roba!!!”. Ma NON basta. Non basta cioè essere sicuri di avere una copia dei dati, bisogna avere anche delle certezze su quando si potrà tornare ad essere operativi.
se un regalo di Natale arriva il 10 di gennaio… non è la stessa cosa!
Questi concetti, che ho esposto volutamente in modo un po’ romanzato, sono illustrati da due acronimi (il nostro settore vive di acronimi):
- RPO (Recovery Point Objective)
- RTO (Recovery Time Objective)
Con RPO intendiamo quanti dati accettiamo di perdere in caso di un guasto (in altre parole a quante ore prima – rispetto al patatrac – risale il backup). Ovviamente più il backup è “vecchio” più i dati che perderò sono tanti. Infatti non posso ripristinare i dati che non avevo ancora salvato.
RTO invece indica in quanto tempo riesco a ripristinare i dati partendo dall’ultimo backup.
Quando affronto un progetto di backup chiedo sempre, dopo aver spiegato quanto appena illustrato, quali siano gli RPO e RTO che il Cliente si attende. La risposta è, spesso, “zero-zero”; cioè “non voglio perdere alcun dato e voglio ripristinare il tutto in tempo zero”.
Quando capita un casino (i clienti che chiamano, i trasportatori nel piazzale,… cose già dette prima) si vorrebbe infatti uscirne subito, possibilmente non perdendo niente…
Ma questo obiettivo, cioè “zero-zero” non è facilmente raggiungibile, a meno di mettere in campo notevoli risorse finanziare e tecnologiche. Però ci si può lavorare…
Bisogna lavorare su due fronti:
- diminuire la probabilità di dover accedere al backup
- adottare strumenti che riducano, con un buon rapporto presto-prestazioni, RPO ed RTO.
Sul primo punto tornerò in un altro articolo, dove affronterò il tema della solidità di un’infrastruttura informatica (cioè la sua capacità di non collassare a fronte di un guasto).
Sul secondo posso dire invece che bisogna distinguere due tipi di “sfighe” che possono capitare:
- perdere dei dati ma con un server ancora funzionante
- perdere completamente il server – e con esso – i dati che vi erano contenuti
se perdiamo una cartella va benissimo usare le shadow copies di Windows (ne ho già parlato in un altro articolo) che sono a costo zero ed implementare un semplice software di backup dei file.
Se invece va in crash l’intero server avere la copia dei dati aggiornata anche ad un’ora prima non ci salva perché, per tornare operativo, devo prendere un altro server, installare Windows, re-installare i programmi che mi interessano e – finalmente – ripristinare i dati dal backup. Si parla a questo punto di giorni!!! (quindi RPO molto buono ma RTO troppo lungo).
Che fare quindi?
Si può pensare, in questi casi, ad un sistema di backup che realizzi localmente una copia dell’intero server e la depositi su un oggetto (un piccolo server) dove – all’occorrenza – posso accendere una copia “virtuale” del server di cui ho appena compiuto il backup. In questo modo se ho fatto il backup un’ora prima,RPO ancora di un’ora ma RTO dell’ordine dei 10 minuti quindi – rispetto ai “qualche giorno” di prima – è un balzo quantico.
Dimensionando opportunamente questo piccolo server (che io chiamo commercialmente “scrigno dei dati”) si può quindi ottenere un buon RPO ed un buon RTO. Avendo tutto il tempo per sistemare il server di produzione.
Poi, siccome è sempre bene avere cintura e bretelle, dallo scrigno posso inviare – se voglio – una copia del mio server anche in server farm (nel caso in cui la sfiga si accanisse…) soddisfando quindi la regola aurea del backup 3-2-1 (vedi altro articolo del blog).
Alla prossima 🙂
