Avere un backup non significa poter ripristinare un sito

Quando si parla di Continuità Operativa, il backup è spesso considerato una delle prime misure da adottare.

L’idea sembra semplice: faccio una copia del sito e, se qualcosa va storto, la ripristino.

Ma avere una copia non significa necessariamente essere in grado di tornare rapidamente a una situazione funzionante.

Il backup è uno strumento. L’obiettivo è un altro: riportare il sistema a produrre nuovamente valore nel modo più rapido e affidabile possibile.

Che cosa significa davvero poter ripristinare

Un sito non è composto soltanto dai file che lo fanno funzionare.

Possono essere necessari database, contenuti, configurazioni, codice, personalizzazioni e altri elementi da cui dipendono i processi che il sito deve svolgere.

Per questo la domanda non dovrebbe essere soltanto:

“Abbiamo fatto il backup?”

Ma:

“Abbiamo conservato tutto ciò che ci serve per tornare a una situazione funzionante?”

Una copia incompleta potrebbe non essere sufficiente.

Un backup troppo vecchio potrebbe riportare il sistema a uno stato che non rappresenta più correttamente ciò che è accaduto.

Una copia disponibile soltanto all’interno dell’infrastruttura che ha subito il problema potrebbe non essere utilizzabile quando serve.

Il backup rappresenta un punto nel tempo

Ogni backup fotografa il sistema in un determinato momento.

Se un e-commerce viene ripristinato nel pomeriggio utilizzando il backup della notte precedente, gli ordini effettuati durante la mattina potrebbero non essere più presenti.

Il sito può tornare online.

Ma potrebbe non avere più traccia di ordini già pagati, account appena creati o altre informazioni necessarie per continuare correttamente il processo di vendita.

Il ripristino del sistema non coincide necessariamente con il ripristino della continuità del processo.

Per questo occorre stabilire quanto indietro nel tempo sia accettabile riportare i dati e quali conseguenze avrebbe la perdita delle informazioni successive all’ultimo backup.

Questo è uno degli aspetti considerati dall’RPO (Recovery Point Objective).

Anche il tempo di ripristino conta

Non è sufficiente sapere che una copia esiste.

Bisogna considerare anche quanto tempo occorre per utilizzarla.

Una strategia che permette di recuperare il sito in poche ore può essere adeguata per un’attività che può tollerare un’interruzione prolungata.

La stessa strategia potrebbe essere insufficiente per un processo che deve tornare operativo molto più rapidamente.

L’RTO (Recovery Time Objective) aiuta a definire quanto tempo può trascorrere prima che il servizio debba tornare disponibile.

Backup e ripristino devono quindi essere valutati anche in funzione del valore che il sito deve continuare a produrre.

Non esiste un unico tipo di copia

La copia necessaria dipende dal cambiamento o dal problema che si vuole gestire.

Prima di una modifica limitata può essere sufficiente conservare una copia della parte interessata.

Prima di un intervento importante può essere opportuno avere una copia completa del sistema.

In altri casi può essere necessario disporre di copie indipendenti dall’ambiente di produzione, proprio per poter recuperare il servizio anche quando l’infrastruttura principale non è disponibile.

La scelta non dovrebbe quindi partire dalla domanda:

“Qual è il sistema di backup migliore?”

Ma da:

“Da quale situazione devo poter recuperare e quale risultato devo ottenere?”

Il backup deve essere utilizzabile

Una copia che non può essere ripristinata non offre la protezione che ci si aspetta.

Per questo la Continuità Operativa non si limita a verificare che il backup sia stato eseguito.

Occorre verificare, quando necessario, che sia possibile utilizzarlo per ottenere il risultato previsto.

Un backup che non è mai stato ripristinato rappresenta una possibilità teorica.

Il test di ripristino permette invece di trasformare quella possibilità in una capacità verificata.

E anche dopo il ripristino il lavoro non è necessariamente concluso.

Il sistema deve essere verificato.

I dati devono essere coerenti.

I processi critici devono continuare a funzionare.

Tornare online non significa automaticamente essere tornati operativi.

Il backup prima del cambiamento

Il backup non serve soltanto quando un sistema si rompe.

Può essere utilizzato anche come punto di ritorno prima di un cambiamento.

Un aggiornamento, una modifica al database o un intervento importante possono produrre risultati inattesi anche quando sono stati pianificati correttamente.

Per questo, prima di un cambiamento, può essere opportuno creare una copia specifica e conservarla come riferimento.

La strategia deve essere proporzionata al rischio.

Non ogni modifica richiede una procedura complessa: in alcuni casi può essere sufficiente una copia mirata; in altri è necessario poter ripristinare l’intero sistema.

L’importante è che, prima di modificare qualcosa, esista una possibilità concreta di tornare indietro.

La domanda non è “ho un backup?”

Il backup è quindi soltanto una parte della strategia di recupero.

La domanda più importante è:

“Se qualcosa va storto, sono in grado di riportare il sito e i processi che supporta a produrre nuovamente valore?”

Per rispondere occorre considerare cosa deve essere recuperato, quanto dato si può perdere, quanto tempo si può rimanere fermi, dove sono conservate le copie e se il ripristino è realmente possibile.

La soluzione deve essere proporzionata al valore da proteggere e al rischio che l’organizzazione è disposta ad accettare.

Non tutto deve essere duplicato.

Non ogni intervento richiede la stessa strategia.

Ma ogni processo critico dovrebbe avere una possibilità concreta di recupero.

La Continuità Operativa non protegge il backup. Protegge la capacità del sito di tornare a produrre valore quando il sistema non è più nello stato previsto.