Best practice per il controllo del backup?

È una situazione comune, quando l'amministratore crea un sistema per il backup automatico e lo dimentica. Solo dopo che un sistema fallisce le notifiche dell'amministratore, quel sistema di backup si è rotto prima o i backup non sono ripristinabili a causa di qualche errore e non ha alcun backup corrente da ripristinare da ... Quindi quali sono le migliori pratiche per evitare tali situazioni ??

Esegui esercitazioni antincendio ... ogni paio di mesi è una buona idea dire che il sistema XYZ è inattivo ... quindi passa attraverso i movimenti per riportarlo online su una nuova VM ecc. Ecc. Mantiene le cose oneste e ti aiuta a catturare errori.

modalità soapbox: ON

Direi che è così semplice che i backup che non vengono testati regolarmente sono inutili.

In un mio precedente lavoro avevamo una politica secondo la quale ogni sistema (produzione, test, monitoraggio dello sviluppo ecc.) Doveva essere ripristinato ogni 6 mesi.

Questo è stato anche il compito dell'amministratore più giovane in modo che la documentazione fosse aggiornata. Junior è stato definito da quanto lavoro ha fatto sul sistema specifico, a volte (abbastanza spesso in realtà) è stato il "gestore del gruppo" a farlo

Avevamo un hardware speciale dedicato a questo (un box Intel e un box IBM / AIX) che era una specifica bassa per tutto tranne lo spazio su disco, dal momento che non era necessario eseguire nulla di reale sull'host ripristinato.

Molto lavoro nelle prime due fasi, ma ci ha portato a semplificare il processo di ripristino, che è la parte importante del backup.

Dal momento che sembra che si stia riferendo al fatto che l'amministratore non nota che il processo di backup "si interrompe" e non tanto che un backup funzionante non ha funzionato correttamente, suggerirei di creare una sorta di script di monitoraggio attorno ai backup.

Quando creo una soluzione di backup domestica, farei una cosa del genere:

• Crea uno script per eseguire il backup dei dati.
• Eseguire il ripristino del test per assicurarsi che lo script funzioni correttamente.
• Nello script o tramite altri mezzi, implementare un modo per tenere traccia dello stato dei backup (esito positivo, esito negativo, eseguito, non eseguito).
• Avere lo stato di monitoraggio monitorato (e-mail, database, qualcosa)

Una volta fatto tutto ciò, dovresti stare bene. Un'ulteriore cosa da fare sarebbe eseguire ripristini di prova regolari. Se hai hardware aggiuntivo da donare alla causa che è.

Dove lavoro, abbiamo un sito caldo, una volta al mese scegliamo casualmente un sistema o un database e andiamo al nostro sito caldo ed eseguiamo un esercizio di ripristino di prova su metallo nudo per garantire la capacità di recuperare i nostri dati.

Onestamente, se i tuoi dati sono molto importanti per te, sarebbe nel tuo interesse investire in alcuni software per gestire i tuoi backup. Ci sono centinaia di prodotti disponibili per questo, da quelli economici e semplici, a quelli di classe enterprise.

Se fai affidamento su una serie di script scritti a mano in esecuzione nel crontab per i backup delle tue aziende, prima o poi probabilmente verrai bruciato.

Disponiamo di versioni "di riferimento" del 60% dei nostri sistemi di "produzione", le utilizziamo per il collaudo finale delle modifiche, ripristiniamo i backup di "produzione" su questi sistemi - verifica il backup e garantisce che entrambi gli ambienti siano in linea tra loro .

Un approccio consiste nello script di un processo di "ripristino" da eseguire periodicamente, ad esempio uno che acquisisce un file di testo specifico dal backup più recente e ne invia un contenuto tramite e-mail. Se è possibile, questo dovrebbe - almeno qualche volta - essere fatto usando una casella diversa da quella che ha creato o eseguito il backup dei dati, solo per assicurarsi che funzionerà se è necessario. Il vantaggio è che puoi essere sicuro che i meccanismi di crittografia / decrittografia, compressione e archiviazione funzionino tutti.

Questo è un po 'più coinvolto per backup specializzati come server di posta elettronica e database, sebbene sia possibile eseguire una sorta di ripristino su piccola scala da un piccolo DB o backup di cassette postali a livello di mattone e verificare il contenuto sia certamente possibile, solo un po' più coinvolto.

Questo approccio, inoltre, non dovrebbe sostituire un ripristino completo periodico per garantire che sia possibile recuperare i dati in caso di emergenza: consente solo di essere un po 'più sicuri dell'integrità del processo di backup quotidiano.

Quando eseguo il ripristino del test, non mi sento davvero a mio agio al punto "sembra bello, i file vengono ripristinati, sembra che non manchi alcun file, anche le dimensioni corrispondono", o al punto "sembra bello, ho avviato la mia applicazione. .. non si arresta in modo anomalo, visualizza alcuni dati decenti ".

Voglio ripristinare server / cluster da zero e quindi utilizzarlo effettivamente per la produzione . Non per un minuto, non per un'ora, ma permanentemente . Se si afferma che il ripristino ha avuto esito positivo, non vi è assolutamente alcun motivo per non avviare una produzione. Questo non è un sistema "sporco", che dovrebbe essere dimenticato. Questo è il sistema che dovrai affrontare dopo un vero disastro. Quindi, se passa sul palco "sembra bello", vivi con esso. Eseguire il backup la notte successiva. Dimentica quello originale. Probabilmente potrete scoprire alcuni difetti che utilizzano questo approccio, e sarete costretti a risolvere tutti loro . Il prossimo ripristino dello stesso sistema ha buone possibilità di successo al 100%.

Ciò include il software e il server di backup. Sì, è necessario ripristinare anche questi.

Non hai budget per acquistare hardware dedicato per il ripristino?

• Fai notare che hai assolutamente bisogno di un budget. In ogni occasione, ricordare ai decisori che non è ancora stato eseguito un test di ripristino valido durante tutto il processo. (E sì, raccogli le prove per coprirti il ​​culo. Mondo duro.)
• Nella maggior parte delle organizzazioni, occasionalmente è necessario che un business esegua la migrazione di un sistema su un altro hardware, quindi sfruttate l'opportunità. Scegli sempre il metodo "Ripristina da backup" per la migrazione, fingendo di aver appena perso l'hardware originale. Sì, significa più tempi di inattività, mi dispiace per quello. Almeno avrai la certezza che il tuo backup sia utile.
• Nessuna migrazione? Forse puoi prendere in prestito dell'hardware per due settimane ed eseguire due test di ripristino (ripristina l'hardware preso in prestito, attendi più di una settimana, ripristina da preso in prestito a originale, vivi con esso). Di solito, se viene acquistato un nuovo hardware per un nuovo sistema e si organizzano le cose correttamente, è possibile prenderlo in prestito facilmente, offrendo di testarlo esaurientemente per due settimane. Se il nuovo hardware non è identico al 100% a quello vecchio, questo renderà il tuo test ancora migliore. Come fai a sapere se ottieni hardware identico in caso di vero disastro?
• Qualche nuovo sistema è stato implementato da te al momento? Puoi testare il ripristino adesso? Non utilizzare hardware aggiuntivo, basta sovrascrivere il nuovo sistema poiché hai nuove conoscenze su come implementarlo rapidamente. Funziona se non ha ancora dati significativi. Ancora una volta, vai alla produzione sulla versione ripristinata, non sulla versione appena reinstallata.

1. Esercitazioni antincendio.
2. Una politica per testare tutti i backup ogni 6 mesi è un'ottima idea
3. Quando si tratta di test, è necessario esaminare ogni applicazione o sistema del backup. Idealmente, ciò che costituisce un backup "riuscito" o "recuperabile" dovrebbe essere elencato nella Descrizione del servizio o SOP (documentazione operativa) per il backup, insieme ad altri dettagli come tempo di conservazione, bladibla.

Probabilmente scoprirai che alcuni tipi di backup possono essere facilmente ripristinati e testati da script (come i database) mentre altri hanno bisogno di input manuali (ripristino di Active Directory). Automatizza il più possibile questo, assicurati che sia in atto un tipo di report e assicurati che "qualcuno" esegua i test manuali anche a intervalli regolari. Un ambiente isolato (copia ridotta di prod) renderà più semplice l'esecuzione di test di ripristino.

Sebbene non testiamo i backup, nel sistema abbiamo sviluppato BackupRadar.com il componente di controllo e reportistica centralizzato del backup. Sentiti libero di provarlo per vedere se aiuta con quel componente. Allega una copia delle e-mail di esito positivo / negativo alla politica di backup e allega anche schermate se il software di backup è in grado di inviare anche quelle.

Grazie Patrick

Assicurati che l'attività di backup sia registrata, quindi scrivi qualcosa (in perl ovviamente) che analizza quei registri alla ricerca di errori, distillali e fatti inviare come e-mail giornaliera.