La frase “abbiamo i backup” produce una sensazione di sicurezza immediata.
I dati vengono copiati ogni notte.
Il gestionale esegue il proprio backup.
Il server conserva diverse versioni.
I documenti sono nel cloud.
Una console mostra tutti gli ultimi job in verde.
Sembra sufficiente.
Ma la domanda realmente importante non è:
“Abbiamo una copia?”
È:
“Se domani mattina questo sistema non esistesse più, quanto tempo ci servirebbe per tornare a lavorare?”
Sono due problemi diversi.
Il backup riguarda la creazione e la conservazione di una copia.
Il recovery riguarda la capacità di utilizzare quella copia per ricostruire un servizio reale.
E la continuità operativa riguarda qualcosa di ancora più ampio: quanto velocemente l’azienda riesce a tornare a svolgere le attività che contano.
Per questo un backup che non è mai stato ripristinato è, almeno in parte, ancora un’ipotesi.
Un job verde dimostra che il backup è partito
Un sistema di backup può dirci moltissime cose.
Che il processo è stato eseguito.
Che una certa quantità di dati è stata trasferita.
Che il repository contiene determinate versioni.
Che non sono stati rilevati errori durante la copia.
Sono informazioni importanti.
Ma non rispondono completamente alla domanda successiva:
quei dati possono essere ripristinati correttamente quando servono?
Un restore può fallire per motivi che durante il backup non erano visibili.
Può mancare una configurazione.
Può mancare una dipendenza.
Il backup può contenere i dati ma non tutto ciò che serve per utilizzarli.
Le autorizzazioni necessarie alla recovery possono non essere disponibili.
Una procedura documentata anni prima può non essere più compatibile con l’ambiente corrente.
Un’applicazione può dipendere da altri sistemi che devono essere ripristinati in un ordine preciso.
La copia può essere perfetta.
E il servizio può comunque non ripartire.
È proprio questa differenza che rende il test di ripristino parte della strategia, non un controllo accessorio.
Ripristinare un file non significa ripristinare un servizio
Per alcuni problemi recuperare un singolo documento è sufficiente.
Per altri no.
Immaginiamo un gestionale.
Il database può essere presente nel backup.
Ma per tornare operativi possono servire anche:
- applicazione;
- configurazione;
- servizi collegati;
- autenticazione;
- certificati;
- integrazioni;
- configurazioni di rete;
- versioni compatibili;
- documentazione operativa.
Lo stesso vale per un sito, un sistema di posta, un file server o un’applicazione interna.
Il dato è fondamentale, ma spesso è soltanto una parte del servizio.
Per questo una strategia di recovery dovrebbe partire non soltanto dall’elenco di ciò che viene copiato, ma dall’elenco di ciò che deve essere ricostruito.
La domanda diventa:
“Di che cosa ha bisogno questo servizio per funzionare davvero?”
È una domanda molto più utile di:
“Quali cartelle stiamo salvando?”
Quanto possiamo perdere?
Una delle decisioni fondamentali riguarda il tempo.
Se l’ultimo backup utilizzabile risale a ieri sera e il problema avviene oggi pomeriggio, una parte del lavoro della giornata potrebbe non essere recuperabile.
Quanto è accettabile?
Un giorno?
Un’ora?
Cinque minuti?
Dipende completamente dal processo.
Questo concetto viene normalmente espresso attraverso il Recovery Point Objective — RPO.
In termini pratici:
quanto indietro nel tempo possiamo permetterci di tornare?
Un archivio aggiornato raramente può tollerare una perdita diversa da un sistema che registra ordini o operazioni continuamente.
Non esiste quindi una frequenza di backup corretta in assoluto.
Esiste una frequenza coerente con la quantità di dati che l’organizzazione è disposta a perdere.
Quanto possiamo restare fermi?
L’altra variabile è il tempo necessario a ripartire.
Una copia può essere perfettamente valida e richiedere molte ore per essere recuperata.
Oppure giorni.
Dipende dalla quantità di dati, dall’architettura, dalla banda disponibile, dall’infrastruttura da ricostruire e dalla complessità della procedura.
Il Recovery Time Objective — RTO descrive il tempo entro il quale il sistema dovrebbe essere riportato a un livello operativo accettabile.
Anche qui non esiste un valore universale.
Un servizio secondario può tollerare un’interruzione lunga.
Un sistema che blocca produzione, ordini, assistenza o accesso ai dati essenziali potrebbe non poterlo fare.
Il problema è che RTO e RPO scritti in un documento non garantiscono che siano raggiungibili.
Il modo migliore per scoprirlo è provare.
Il restore test trasforma una supposizione in una misura
Un test di ripristino serve innanzitutto a rispondere a domande concrete.
La copia è leggibile?
È completa?
Quale recovery point possiamo realmente utilizzare?
Chi possiede gli accessi necessari?
Quanto tempo serve per recuperare i dati?
Quanto tempo serve per ricostruire il servizio?
Quali passaggi dipendono da conoscenza non documentata?
Quali sistemi devono essere ripristinati prima di altri?
Il test genera quindi qualcosa che il semplice backup non può generare:
evidenza operativa.
Dopo un recovery test non dobbiamo più dire:
“Dovremmo riuscire a ripartire in qualche ora.”
Possiamo dire:
“Nell’ultimo test abbiamo impiegato questo tempo e abbiamo incontrato questi problemi.”
È una differenza enorme.
Il diagramma corretto non è backup → sicurezza
- Criticità
- Backup
- Test
- Misura
- Correzione
Il percorso deve essere:
Criticità → Backup → Test → Misura → Correzione
Dopo la correzione il ciclo può ricominciare.
La continuità non è un risultato raggiunto una volta per sempre.
L’ambiente cambia.
Cambiano applicazioni.
Cambiano dati.
Cambiano persone.
Cambiano credenziali e permessi.
Cambiano volumi.
Cambiano integrazioni.
Una procedura verificata due anni fa può non rappresentare più il sistema che abbiamo oggi.
Non tutti i sistemi hanno la stessa priorità
In caso di incidente, cercare di ripristinare tutto contemporaneamente può essere meno efficace che stabilire prima una sequenza.
Quale sistema blocca realmente il lavoro?
Quale servizio è necessario perché gli altri possano funzionare?
Quali informazioni devono essere disponibili immediatamente?
Quali componenti possono aspettare?
La continuità operativa richiede una gerarchia.
Potremmo avere decine di sistemi ma soltanto alcuni sono realmente critici nelle prime ore di un incidente.
Sapere quali siano permette di progettare backup, recovery e investimenti in modo proporzionato.
Un’infrastruttura non diventa più resiliente perché tutto viene trattato come critico.
Diventa più resiliente quando sappiamo cosa deve tornare operativo per primo.
Il ransomware ha cambiato anche il modo di pensare ai backup
Per molto tempo il backup è stato visto principalmente come protezione da guasti hardware, errori umani o cancellazioni accidentali.
Oggi dobbiamo considerare anche un altro scenario:
chi compromette l’infrastruttura può tentare di compromettere anche il sistema di backup.
Se una copia è sempre accessibile dallo stesso ambiente, attraverso gli stessi account amministrativi e le stesse credenziali, un attacco può riuscire a colpire sia la produzione sia il meccanismo utilizzato per recuperarla.
Da qui deriva l’importanza di concetti come:
- copie isolate;
- storage offline quando appropriato;
- immutabilità;
- separazione dei privilegi;
- versioni multiple;
- protezioni specifiche contro cancellazione o modifica.
Ma anche una copia perfettamente isolata deve essere ripristinabile.
La resilienza nasce dall’unione delle due cose:
proteggere il recovery point e saperlo utilizzare.
Essere nel cloud non elimina il problema
Il cloud ha migliorato enormemente la disponibilità e la possibilità di costruire sistemi resilienti.
Ma “è nel cloud” non è una strategia di recovery.
Dobbiamo comunque capire:
- cosa viene protetto automaticamente dal provider;
- cosa rimane responsabilità dell’organizzazione;
- quali versioni vengono conservate;
- per quanto tempo;
- cosa accade in caso di cancellazione;
- come si esegue un recupero completo;
- quali dipendenze devono essere ricostruite.
Alta disponibilità, replica e backup risolvono problemi diversi.
Una replica può mantenere un servizio disponibile durante un guasto.
Ma può anche replicare rapidamente una modifica indesiderata o una cancellazione.
Un backup conserva uno stato precedente.
Ma non garantisce da solo un tempo di recovery accettabile.
Per questo affidabilità e continuità richiedono più livelli.
Il test deve includere anche le persone
Una recovery procedure non viene eseguita da sola.
Qualcuno deve riconoscere l’incidente.
Qualcuno deve decidere quale recovery point utilizzare.
Qualcuno deve avere gli accessi.
Qualcuno deve sapere dove trovare documentazione e strumenti.
Qualcuno deve verificare che il servizio ripristinato funzioni.
Se tutto questo dipende da una sola persona, abbiamo un’altra vulnerabilità.
Un recovery test serve quindi anche a capire quanto la conoscenza sia distribuita.
La documentazione esiste?
È accessibile durante un incidente?
È aggiornata?
Un’altra persona può seguirla?
Le responsabilità sono chiare?
Il sistema tecnologico può essere ridondante mentre la conoscenza operativa rimane un singolo punto di fallimento.
Il momento peggiore per imparare a ripristinare è durante l’incidente
Quando un sistema importante è fermo, il tempo cambia valore.
Ogni minuto pesa di più.
Le persone lavorano sotto pressione.
Le decisioni vengono prese più velocemente.
Gli errori diventano più costosi.
Non è quello il momento ideale per scoprire:
- dove si trova una copia;
- quale sia quella corretta;
- quali password servano;
- quale macchina debba essere ricostruita prima;
- quanto tempo occorra;
- se la procedura funzioni ancora.
Un test effettuato in condizioni controllate serve proprio a spostare queste scoperte prima dell’incidente.
Ogni problema trovato durante una prova è un problema in meno da trovare durante una crisi reale.
Una strategia di backup dovrebbe produrre risposte, non soltanto copie
Alla fine, un’azienda dovrebbe riuscire a rispondere almeno a poche domande fondamentali.
Quali sistemi sono realmente critici?
Qual è l’ultimo punto recuperabile?
Quanta perdita di dati è accettabile?
Quanto tempo serve realmente per ripartire?
Dove sono conservate le copie?
Sono protette anche da compromissioni dell’ambiente principale?
Abbiamo mai eseguito il restore completo?
Quando è stato fatto l’ultimo test?
Chi sa eseguire la procedura?
Se queste risposte non esistono, il problema non è necessariamente che il backup sia sbagliato.
È che stiamo ancora gestendo copie, non una vera capacità di recovery.
Il backup protegge una copia. Il ripristino protegge l’operatività
La differenza può sembrare semantica.
Non lo è.
Un backup è un componente tecnico.
La capacità di recovery è una proprietà del sistema.
La continuità operativa è una proprietà dell’organizzazione.
Sono tre livelli diversi.
E devono essere progettati insieme.
La domanda quindi non dovrebbe essere:
“Abbiamo i backup?”
Dovrebbe essere:
“Se perdiamo questo sistema adesso, sappiamo esattamente come e in quanto tempo tornare operativi?”
Se la risposta deriva da un test reale, abbiamo una capacità.
Se deriva soltanto da una supposizione, abbiamo ancora del lavoro da fare.