Problemi affrontati
- Un backup completato con successo non dimostra da solo che un servizio possa essere ripristinato.
- Senza una sequenza di recupero condivisa, durante un incidente si rischiano decisioni lente o incoerenti.
- I test occasionali non producono evidenze sufficienti per capire se la procedura è ancora applicabile.
- RTO e RPO non definiti rendono impossibile stabilire priorità e criteri di successo.
Soluzione implementata
Un runbook documenta attivazione, contenimento, ripristino e chiusura dell'incidente. Ogni servizio ha una priorità, un RTO e un RPO; i ripristini di prova vengono eseguiti in un ambiente isolato secondo una cadenza definita, con esito, tempi e anomalie registrati.
Risultati
- La procedura è eseguibile anche sotto pressione e indica chi decide, cosa ripristinare prima e quando dichiarare concluso il recupero.
- I backup vengono verificati sia a livello di integrità sia attraverso l'avvio e il controllo applicativo di campioni reali.
- Ogni test lascia evidenze confrontabili nel tempo: data, sorgente, versione della procedura, durata, esito e azioni correttive.
- Le modifiche all'infrastruttura fanno scattare una revisione del runbook e un nuovo test mirato.
Descrizione tecnica
Un piano di disaster recovery (DR) non è solo un elenco di backup. È una procedura operativa che permette di riportare i servizi a uno stato funzionante dopo la perdita di un nodo, dello storage, di una configurazione o dell'intero sito. Questo documento definisce il flusso di recupero e il programma dei test che ne dimostrano l'efficacia.
Obiettivi e criteri
Per ogni servizio si definiscono prima due obiettivi:
- RPO (Recovery Point Objective): la quantità massima di dati che si accetta di perdere, espressa come intervallo temporale.
- RTO (Recovery Time Objective): il tempo massimo entro cui il servizio deve tornare disponibile.
La priorità di recupero deve essere esplicita. In linea generale si ripristinano prima rete, DNS e autenticazione, poi storage e piattaforma di virtualizzazione, quindi i servizi applicativi e infine quelli non essenziali. La sequenza effettiva va adattata alle dipendenze documentate nell'inventario.
Attenzione
I valori di RPO e RTO sono obiettivi da verificare con i test, non promesse ricavate dalla velocità teorica del backup.
Quando attivare la procedura
Il runbook viene attivato quando un evento compromette la disponibilità o l'integrità dei servizi: guasto hardware, corruzione dello storage, errore umano, aggiornamento non riuscito, perdita del nodo o sospetto ransomware. L'operatore registra subito:
- ora di rilevazione e servizi coinvolti;
- sintomi osservati e ultime modifiche effettuate;
- backup disponibili e loro ultimo esito verificato;
- persone coinvolte e canale usato per coordinare l'intervento.
Prima di ripristinare si preservano le evidenze e si contiene il guasto: si isolano i sistemi sospetti, si interrompono job che potrebbero sovrascrivere dati e si evita di collegare alla rete una macchina ripristinata finché non è stata controllata.
Procedura di ripristino
1. Valutazione e scelta del punto di recupero
Si identifica la causa probabile, si conferma l'ambito dell'incidente e si sceglie il punto di ripristino più recente che precede l'evento. Se l'integrità dell'ultima copia è dubbia, si usa una copia precedente e si annota il motivo. Non si modificano i backup originali durante l'analisi.
2. Preparazione dell'ambiente
Si verifica la disponibilità della piattaforma di destinazione, dello storage e della rete isolata. Si controllano spazio libero, credenziali di emergenza, accesso al repository e dipendenze del servizio. Il ripristino viene eseguito con un identificativo temporaneo e senza indirizzi o record DNS in conflitto.
3. Ripristino tecnico
Per una macchina virtuale, la sequenza minima è simile a questa. I valori sono esempi: l'operatore deve sostituirli con quelli dell'inventario e del repository scelto.
qmrestore pbs-locale:backup/vm/105/<snapshot> 9100 --storage local-zfs --unique 1
qm set 9100 --delete net0
qm start 9100
qm agent 9100 pingSi ripristinano quindi configurazione, dati e segreti necessari, nell'ordine previsto dalle dipendenze. Solo dopo i controlli in isolamento si abilita la connettività richiesta e si aggiorna il servizio di produzione.
4. Validazione e rientro
Il controllo non termina con l'avvio della VM. Si verifica almeno che il sistema operativo risponda, che il servizio ascolti sulla porta prevista, che i dati campione siano leggibili e che monitoraggio e log non mostrino errori anomali. Per un servizio critico si esegue anche una transazione o una query di prova non distruttiva.
Quando il servizio è stabile, si registra l'orario di ritorno, si confrontano RTO e RPO con l'obiettivo, si riattivano i backup e si controlla che il nuovo stato sia nuovamente protetto. La macchina temporanea e gli artefatti di prova vengono rimossi solo dopo aver conservato i log necessari.
Piano dei test periodici
| Frequenza | Test | Criterio di successo | Evidenza |
|---|---|---|---|
| Ogni giorno | Esito job, spazio, errori e alert | Nessun job critico fallito senza presa in carico | Report o alert chiuso |
| Ogni settimana | Verify dei backup e controllo della replica | Integrità confermata e copia aggiornata | Log del verify e della replica |
| Ogni mese | Ripristino di una VM o di un container in rete isolata | Avvio, guest agent e controllo applicativo riusciti | Verbale con durata ed esito |
| Ogni trimestre | Ripristino di un servizio critico e prova end-to-end | RTO/RPO rispettati e dipendenze funzionanti | Report firmato e azioni correttive |
| Dopo ogni modifica importante | Test mirato della parte modificata | Nessuna regressione nella catena di recupero | Change record collegato al test |
I campioni mensili ruotano tra le classi di servizio, così non si verifica sempre la stessa macchina. Almeno una prova trimestrale usa la copia fuori sede o un percorso equivalente a quello necessario nello scenario di perdita del sito principale.
Registrazione dell'esito
Ogni test produce una scheda con almeno: data e operatore, scenario simulato, sorgente e timestamp del backup, versione del runbook, ambiente di destinazione, ora di inizio e fine, controlli eseguiti, risultato, anomalie e responsabile dell'azione correttiva. Un test fallito resta aperto fino alla ripetizione riuscita; non viene trasformato in “pass” solo perché il backup successivo è andato a buon fine.
Il runbook viene revisionato dopo ogni incidente, test fallito o modifica a storage, rete, autenticazione, orchestrazione e servizi critici. La versione usata durante ogni prova viene conservata insieme al risultato, in modo da poter ricostruire esattamente cosa è stato verificato.
Collegamento con la strategia di backup
La procedura completa la strategia di backup 3-2-1 con verifica automatica dei ripristini, ma non la sostituisce: la ridondanza delle copie riduce il rischio di perdita dei dati, mentre i test dimostrano che quelle copie possono diventare un servizio funzionante.