Come testare un restore, non solo un backup

Ogni console di backup del mondo può mostrarvi una colonna di spunte verdi. Nessuna può dirvi se la vostra azienda sarà di nuovo operativa per l'ora di pranzo dopo una brutta notte. Solo un restore può dirvelo, e l'unico restore di cui potete fidarvi è uno che avete già fatto. Ecco come testare i restore perché il risultato significhi qualcosa.

Cosa prova davvero un job verde

Un job di backup riuscito prova che un job è girato, ha letto dei dati e li ha scritti da qualche parte senza un errore che il software abbia riconosciuto. Non prova che i dati siano completi, che la macchina che vi sta a cuore fosse nel job, che la copia possa essere riletta, o che l'applicazione parta da essa.

Ci sono tre cose da testare: la copertura (tutto ciò che dovrebbe essere salvato viene effettivamente salvato?), la recuperabilità (la copia può essere letta e avviata?) e il tempo (quanto dura davvero un recupero). La maggior parte delle organizzazioni non ne testa nessuna con regolarità.

Passo uno: controllate la copertura contro la realtà

I job di backup vengono definiti in un certo momento. L'infrastruttura continua a cambiare. Una nuova macchina virtuale creata accanto alle vecchie, un database spostato su un nuovo host, un server rinominato: ognuno può cadere fuori da ogni job senza che venga sollevato un solo errore.

Confrontate quindi l'elenco di ciò che esiste con l'elenco di ciò che è protetto. Esportate l'inventario dal posto che sa cosa sta girando, l'hypervisor, la piattaforma cloud o il DCIM, e l'elenco degli oggetti protetti dal sistema di backup, poi confrontateli:

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

La prima lista è quella pericolosa. La seconda è il disordine che la nasconde. Ogni voce della prima lista ha bisogno di una decisione: aggiungerla a un job, o scrivere che deliberatamente non ha backup e perché.

Passo due: ripristinate a più di un livello

La recuperabilità ha dei livelli, e ogni livello cattura problemi che quello sotto non vede.

Livello file. Ripristinate un campione di file in una posizione alternativa e confrontateli con checksum contro la sorgente o una copia buona nota. Questo cattura supporti illeggibili e catene spezzate di backup incrementali.

Livello macchina. Avviate un intero server o una macchina virtuale dal backup. Questo cattura volumi di boot mancanti, driver e il disco che era stato silenziosamente escluso dal job. La maggior parte delle piattaforme di backup enterprise, Veeam tra queste, può avviare una macchina direttamente dal repository di backup in un lab isolato esattamente per questo scopo.

Livello applicativo. Dimostrate che l'applicazione funziona dalla copia ripristinata. Per un database, significa che parte, supera il proprio controllo di consistenza, e contiene i record più recenti che vi aspettate per l'ora del backup:

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Per gli strumenti di backup a livello file esistono controlli di integrità che rileggono i dati archiviati, per esempio borg check --verify-data su un repository Borg.

Passo tre: ripristinate in un lab, non in produzione

Una macchina ripristinata è una copia della produzione, con gli indirizzi, le credenziali, i job pianificati e la posta in uscita della produzione. Portatela su sulla rete reale e può rispondere a richieste destinate al server live, inviare ai clienti una raffica di email duplicate, o eseguire una seconda volta il job di fatturazione di ieri notte.

I test di restore appartengono quindi a una rete isolata senza rotta verso la produzione e senza rotta verso internet. Prima di avviare qualunque applicazione in quel lab, disabilitate lo scheduler e la posta in uscita sulla copia ripristinata. Fatene un passo scritto del test, così nessuno deve ricordarselo.

Passo quattro: cronometratelo

Il tempo di recupero sulla carta è una stima. Quello che conta è misurato: dal momento in cui qualcuno decide di ripristinare, passando per trovare il punto di restore giusto, spostare i dati, avviare i servizi e controllare l'applicazione, fino alla prima transazione reale riuscita. I restore grandi sono spesso limitati da un throughput che nessuno ha misurato, o da un passo che solo una persona sa fare. Cronometrare l'intera sequenza trova entrambi.

Passo cinque: scrivetelo

Tenete una breve voce per ciascuno:

• Data, e chi l'ha eseguito.
• Cosa è stato ripristinato, da quale punto di restore.
• Quale livello è stato testato: file, macchina o applicazione.
• Tempo impiegato, da un capo all'altro.
• Qualunque cosa sia fallita, vi abbia sorpreso o abbia richiesto conoscenze non scritte.
• Cosa è stato cambiato di conseguenza.

Anche il progetto sottostante conta

Il test prova che i backup esistono e funzionano oggi. Il progetto decide se esisteranno ancora dopo una brutta giornata. La regola che conta di più è che i backup vengono prelevati. Il sistema di backup entra nella produzione e prende ciò di cui ha bisogno; la produzione non ha alcun percorso di rete verso il sistema di backup e nessuna credenziale per esso. Così un intruso che possiede un server di produzione non può raggiungere i backup di quel server per cancellarli. L'accesso append-only per gli strumenti a livello file aggiunge una seconda serratura, e la cronologia sul repository significa che una copia di prima del problema esiste ancora.

Come lo facciamo noi

I nostri backup sono pull-only per progetto e imposti sulle appliance firewall, con la sola rete di gestione in grado di raggiungere i sistemi di backup e recupero. Usiamo Veeam per macchine virtuali, server fisici e server SQL, e un hub di backup deduplicante che preleva file e dati di database Linux usando chiavi ristrette e append-only. La copertura viene controllata contro l'inventario live, le pianificazioni sono impostate sui tempi di esecuzione misurati, e i restore completi vengono eseguiti anche ogni settimana.

Se non avete mai cronometrato un restore completo del vostro sistema più importante, è da quello che bisogna cominciare, e siamo lieti di aiutarvi a pianificarlo.

cta: Parla con un ingegnere

Related

• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/network-attached-storage/