Backup e DR
Un backup riuscito non garantisce un ripristino riuscito
Un job con esito positivo dice che i dati sono stati copiati. Non dice se si possono rimettere in produzione, in quanto tempo e con quali dipendenze.
La maggior parte dei software di backup chiude ogni job con un esito: completato, completato con avvisi, fallito. È un'informazione utile, e controllarla ogni giorno è il minimo indispensabile. Ma «completato» risponde a una sola domanda: i dati previsti sono stati copiati senza errori?
Le domande che contano quando qualcosa si rompe sono altre: i dati si possono ripristinare? In quanto tempo? Il servizio riparte davvero, o manca un pezzo?
Che cosa dice, e che cosa non dice, un job completato
Un esito positivo indica in genere che il software ha letto i dati di origine e li ha scritti nella destinazione. A seconda del prodotto e della configurazione, può includere anche controlli di integrità sui blocchi scritti. Non garantisce invece che:
- il perimetro sia corretto: una nuova macchina virtuale o una nuova cartella condivisa potrebbe non essere mai stata inclusa;
- i dati siano coerenti a livello applicativo: un database copiato mentre scrive può risultare non utilizzabile se il backup non è stato eseguito in modo consistente con l'applicazione;
- il ripristino sia compatibile con i tempi dell'azienda: recuperare molti terabyte da un archivio remoto può richiedere molto più tempo di quanto l'attività possa restare ferma;
- il servizio riparta: un server ripristinato può avere bisogno di altri sistemi per funzionare.
Livelli di verifica
La verifica dei backup non è un'attività unica, ma una scala. Ogni livello dà più garanzie del precedente e richiede più lavoro.
- Controllo dell'esito dei job. Si legge il risultato di ogni esecuzione e si interviene su errori e avvisi. È la base, da fare con continuità.
- Verifica dei dati salvati. Controlli di integrità sulle copie, dove il software lo consente, per individuare dati corrotti nella destinazione.
- Ripristino di file. Si recupera un insieme di file o cartelle e si controlla che si aprano. Dimostra che i dati sono leggibili.
- Ripristino di un sistema. Si ripristina una macchina virtuale in un ambiente isolato e si verifica che si avvii e che i servizi partano.
- Ripristino di un servizio completo. Si riportano in funzione insieme tutti i sistemi da cui dipende un'applicazione e si verifica che gli utenti possano lavorare.
Non serve arrivare all'ultimo livello per ogni sistema, né con la stessa frequenza. La profondità e la cadenza dei test dipendono da quanto è critico ciò che si sta proteggendo.
Le dipendenze applicative
Le applicazioni aziendali raramente vivono su un solo server. Quando si pianifica un ripristino conviene ragionare per servizio, non per macchina.
Esempio illustrativo
Un gestionale può dipendere da un server applicativo, da un database su un'altra macchina, dal servizio di directory per l'autenticazione degli utenti, dal DNS, da un server di licenze e da una cartella condivisa per allegati e stampe. Ripristinare correttamente il solo database non rimette in funzione il gestionale se uno degli altri elementi manca, o se viene ripristinato in uno stato incoerente con gli altri.
Mappare queste dipendenze serve anche a stabilire l'ordine di ripristino: prima i servizi di base (rete, directory, DNS), poi i dati, infine le applicazioni.
RPO e RTO: due numeri da decidere prima
Due parametri traducono le esigenze dell'azienda in requisiti tecnici. Andrebbero definiti per ogni servizio importante, insieme a chi ne è responsabile.
| Parametro | Domanda | Che cosa determina |
|---|---|---|
| RPO Recovery Point Objective | Quanti dati, misurati nel tempo, posso permettermi di perdere? | La frequenza dei backup o delle repliche. |
| RTO Recovery Time Objective | Entro quanto tempo il servizio deve tornare disponibile? | Tecnologie, destinazioni e procedure di ripristino. |
Se l'ultimo backup utile di un sistema è di ieri sera, nel caso peggiore si perde una giornata di lavoro: quello è l'RPO effettivo, che lo si sia deciso o no. Allo stesso modo, il tempo necessario a ripristinare dipende da dove si trovano le copie e da quanto sono grandi. Solo un test di ripristino dice qual è l'RTO reale, e se è compatibile con quello che l'azienda si aspetta.
Copie al riparo dagli stessi incidenti
Un backup che si trova nella stessa rete, con le stesse credenziali amministrative dei sistemi protetti, può essere compromesso dallo stesso incidente: un ransomware che raggiunge il repository, un errore amministrativo, un guasto fisico nella sala server. Per questo si tengono più copie, su supporti diversi e almeno una lontana dall'ambiente principale, protetta contro la cancellazione o la modifica oppure non raggiungibile dalla rete di produzione.
Rendere i test un'abitudine
- Pianificarli con una cadenza proporzionata alla criticità dei sistemi, invece di eseguirli solo dopo un incidente.
- Documentarli: che cosa è stato ripristinato, in quanto tempo, con quali problemi.
- Ripeterli dopo i cambiamenti: una migrazione, un nuovo applicativo o un aggiornamento importante possono invalidare procedure che funzionavano.
- Coinvolgere chi usa i sistemi, quando si verifica un servizio completo: è l'unico modo per sapere se «funziona» davvero.
Un piano di backup si giudica dai ripristini riusciti, non dai job completati.