12 errori comuni durante il backup dei database

di Alexey Kovyazin, 11 novembre 2015

Scarica PDF (inglese) Questo articolo era inizialmente destinato agli sviluppatori e agli amministratori di Firebird DBMS, ma i contatti con gli amministratori di altri database hanno reso evidente che la maggior parte degli errori è comune anche tra loro e che letteralmente tutti inciampano quasi sulle stesse pietre. Se puoi aggiungere qualcosa a questo elenco (anche qualcosa di specifico per un particolare DBMS), contattaci via e-mail [email protected].

1. Eliminare la copia di backup precedente prima che venga creata una nuova copia di backup

Questo errore è molto comune tra i principianti che non si rendono conto che lo scopo principale di una copia di backup del database non è solo creare una copia del database, ma rendere il più breve possibile il tempo di inattività di un sistema informativo (di cui il database è una parte importante).

Di conseguenza, il sistema rimane non protetto dal momento in cui viene eliminata l’ultima copia di backup fino al momento in cui viene creata quella nuova, perché durante questo periodo il database non ha alcuna copia di backup. Poiché la creazione di una copia di backup può richiedere parecchio tempo, è il momento perfetto perché la legge di Murphy entri in azione. Questo approccio funziona particolarmente bene quando è combinato con il Problema 7 (vedi sotto).

Raccomandazioni: non eliminare la copia di backup precedente prima che venga creata quella nuova! (e non creare una nuova copia di backup in un file già esistente).

Raccomandazione per Firebird: c’è uno strumento FBDataGuard incluso in HQbird (un pacchetto di distribuzione avanzato di Firebird) che elimina la copia di backup più vecchia nella cronologia solo dopo che ne è stata creata una nuova.

2. Sovrascrivere un database esistente durante il ripristino da una copia di backup

Questo errore è meno comune, anche se i risultati possono essere molto peggiori. Se la copia di backup non è stata verificata e risulta corrotta (vedi Problema 6), non avrai né la copia precedente del database né una copia di backup valida.

Un pasticcio del genere di solito accade di venerdì sera, quando le cose si fanno concitate e quando le direttive della direzione sono un po’ contraddittorie. Un po’ di sfortuna e ti aspetta un languido fine settimana nella sala server.

Firebird ha una sorta di protezione contro questo errore: non sarà possibile ripristinare un database da una copia di backup con l’utilità gbak se il suo switch predefinito -create è attivo e se il nome del file specificato punta a un database esistente. Sfortunatamente, c’è un modo per aggirare questa protezione: lo switch -rep consente comunque di sovrascrivere il file esistente.

Raccomandazione: non sovrascrivere mai il file di un database in funzione senza una direttiva scritta della tua direzione.

Raccomandazione per Firebird: usa FBDataGuard perché non sovrascrive mai il file del database.

3. Usare il backup/ripristino in un unico passaggio senza utilizzare un file di backup intermedio

I flussi di input/output standard rendono possibile fare un simpatico trucco con molti DBMS (incluso Firebird): implementare un backup in streaming con il ripristino del database da esso in un colpo solo. Di conseguenza non viene creato alcun file di backup intermedio. È comodo per la manutenzione ordinaria e per eseguire un’operazione di ripristino di prova (a condizione che sia disponibile un’altra copia di backup), ma non devi usarlo per il backup automatico!

Ad esempio, se durante questo processo di backup/ripristino si verifica un grave guasto del disco, il database iniziale potrebbe danneggiarsi mentre non è ancora stato creato alcun nuovo database. Naturalmente, se tieni conto del Problema 1 e c’è una copia del database dal tentativo precedente, andranno persi solo i dati creati o aggiornati nel database dopo la creazione di quella copia.

Raccomandazioni: non usare il backup/ripristino in un unico passaggio in modalità automatica e verifica sempre la disponibilità di una copia sufficientemente aggiornata in modalità manuale.

4. Memorizzare le copie di backup e il database sullo stesso dispositivo fisico

Molti di voi potrebbero trovare divertente che il consiglio che diamo sia un po’ infantile: l’ABC del backup. Vero, è così, ma il database e il disco possono finire per essere memorizzati sullo stesso sistema di archiviazione dati a causa della popolarità degli ambienti virtuali. E fallirà certamente nel momento più inopportuno. Inoltre ci sono ancora persone che credono che non possa succedere nulla ai loro dati se usano array RAID (versione 1 o superiore :)). Inoltre, ci sono persone che credono che alcuni server “di marca” siano a prova di guasto, ma quello è un caso speciale.

Raccomandazioni: non memorizzare le copie di backup e il database sullo stesso dispositivo, per quanto affidabile possa sembrare.

5. Nessun controllo sul completamento con successo del processo di backup

È un errore piuttosto comune sia tra gli amministratori sia tra i responsabili dei reparti IT. Se non controlli i risultati del processo di backup, tanto vale non eseguirlo affatto. Devi ricevere notifiche sul completamento con successo del processo di backup via e-mail o, meglio ancora, anche via SMS. E l’assenza di tali notifiche è un segnale di un problema!

Un lettore attento che è arrivato a questo punto del nostro articolo (anche se è ancora troppo presto per dare un premio per questo) potrebbe chiedere: “Ma cosa c’entra la direzione?” Ecco cosa: l’amministratore di solito configura il processo di backup, ma trova troppo noioso controllare le notifiche, soprattutto quando sono archiviate in una cartella separata, quindi non è mai troppo chiedere report aggiuntivi sullo stato del processo. È in merito alla questione di chi sia da biasimare quando sembra che le copie di backup ci fossero, ma in realtà non ci sono nel momento in cui ne hai bisogno :)

! una volta combinato con il Problema 2, non abbiamo né il database né la sua copia di backup.

Raccomandazioni: usa strumenti di automazione del backup in grado di monitorare i processi di backup riusciti e non riusciti, notificare agli utenti i problemi e offrire strumenti di controllo riepilogativo (è particolarmente rilevante quando devi controllare decine e centinaia di processi di backup su server diversi).

Raccomandazione per Firebird: FBDataGuard verifica se il processo di backup è stato completato e invia la notifica corrispondente. Per i sistemi con molti database esiste un monitoraggio riepilogativo di secondo livello con l’aiuto dello strumento Control Center che consente di vedere gli stati di tutti i server e i database monitorati su un’unica pagina.

6. Nessuna validazione del backup

Il fatto che le copie di backup siano memorizzate da qualche parte non significa che possano essere lette da lì.

Ecco perché devi verificare regolarmente le copie di backup che crei per assicurarti che non siano corrotte o copiate su /dev/null.

Raccomandazione per Firebird: puoi automatizzare la validazione del backup con l’aiuto di FBDataGuard.

7. Nessun controllo dello stato del database quando si usano copie di backup non verificate

Di solito, i database utilizzano diversi tipi di backup: dump, copie di backup regolari, ecc. Senza entrare nei dettagli, possiamo individuare due categorie: verificate e non verificate. Nel caso di Firebird, si tratta di gbak e nbackup.

Gbak legge l’intero database a livello di record per creare un file di backup e crea un database inserendo record in un nuovo database, verificando così la copia di backup (ci sono modi perché gli errori si insinuino nella copia ripristinata, ma quella è un’altra maniera per l’amministratore del database di fare pasticci legati a una migrazione mal organizzata) e il database stesso (se può essere letto dall’inizio alla fine, molto probabilmente non è corrotto).

Nbackup (alias backup incrementale) blocca temporaneamente il file principale del database per gli aggiornamenti (nello stato consistente) e rende possibile copiare rapidamente il file del database (completamente o parzialmente/incrementalmente).

Nel caso di database Firebird di grandi dimensioni (più grandi di 500 GB), è consigliabile usare nbackup per non rallentare le operazioni degli utenti, ma allo stesso tempo è necessario validare il database perché le copie di backup non verificate che crea sono copie di pagine del database e, se un errore risiede a livello di record (a causa di un guasto della RAM) o a livello logico, una copia di backup non verificata lo conterrà così come il database originale.

Per evitarlo, dovresti usare la validazione online per il database originale (la validazione online con l’aiuto di gfix è disponibile a partire dalla versione 2.5.4 di Firebird, mentre il nostro strumento FBDataGuard supporta la validazione online del database per le versioni 1.5-2.5).

Inoltre, è consigliabile eseguire un backup verificato ogni tanto (una volta alla settimana, ad esempio) in aggiunta al backup non verificato.

Raccomandazione per Firebird: oltre al controllo dello stato online, FBDataGuard consente di testare il processo di ripristino del backup in modalità automatica.

8. Nessun controllo dello spazio libero per le copie di backup

In realtà, è un errore classico: se non c’è abbastanza spazio, le copie di backup occupano tutto lo spazio libero e il processo termina con un errore. Memorizzare le copie di backup su un disco insieme al database può portare a un’interruzione del funzionamento del database e memorizzarle sul disco di sistema può provocare un guasto del sistema.

In combinazione con il Problema 4, il miglior esito possibile sarà quello in cui il sistema smette di funzionare perché anche il database ha bisogno di spazio libero, ma è occupato dalle copie di backup. Quanto alla combinazione con i Problemi 5 e 2, ci lascia di nuovo senza né il database né la sua copia di backup.

Raccomandazioni: usa strumenti di backup che prevedono la dimensione del backup e ti avvisano della possibile mancanza di spazio libero.

Raccomandazione per Firebird: FBDataGuard controlla la dimensione dello spazio libero a scopo di backup e anche la dimensione dello spazio libero sul disco con i database e sul disco di sistema.

9. Nessun controllo del tempo impiegato per creare una copia di backup

Il processo di backup richiedeva letteralmente 40 minuti solo sei mesi fa e poi improvvisamente richiede già tre ore: perché? La dimensione del database può essere aumentata o un disco può essere caduto dal tuo array RAID, con conseguente prestazione di scrittura notevolmente più lenta, e tutte le tue copie di backup potrebbero essere in procinto di lasciare questo mondo. Oppure un tuo buon collega può aver avviato un altro sistema di backup contemporaneamente (a proposito, Firebird consente di eseguire più processi di backup contemporaneamente, anche se non è del tutto chiaro perché uno possa averne bisogno). Se non controlli il tempo impiegato per creare una copia di backup, potresti trascurare un problema appena emerso e perdere la possibilità di risolverlo prima che diventi massiccio.

Inoltre, se il sistema di backup non monitora gli stati delle attività di backup e le esegue solo secondo la pianificazione, potresti facilmente “bruciare le tappe”, il che significa la situazione in cui il sistema avvia un nuovo processo di backup mentre il precedente non è ancora terminato.

Raccomandazioni: usa strumenti che controllano il tempo impiegato dal processo di backup!

Raccomandazione per Firebird: FBDataGuard controlla il tempo impiegato dal processo di backup.

10. Eseguire il backup del database mentre sono in corso gli aggiornamenti del sistema operativo

È un problema molto comune, soprattutto in combinazione con il Problema 9 e con gli aggiornamenti automatici di Windows abilitati (per impostazione predefinita, gli aggiornamenti vengono applicati alle 3 del mattino). Nel migliore dei casi porta a un rallentamento, ma se il sistema operativo viene riavviato per applicare gli aggiornamenti, la copia di backup sarà danneggiata. Almeno la buona notizia è che il sistema operativo non viene aggiornato ogni giorno.

Raccomandazioni: pianifica gli aggiornamenti del sistema operativo quando non interferiscono con il processo di backup.

11. Eseguire il backup del database con l’aiuto di strumenti di backup dei file o di backup delle macchine virtuali mentre il server del database è in esecuzione

Molti amministratori dimenticano che qualsiasi DBMS ha una cache attiva e complessa che contiene i dati letti e scritti mentre i file del database stessi sono aperti in modalità accesso casuale. Ecco perché è necessario usare tipi speciali di backup invece del semplice backup dei file (inclusa la semplice copia dei file del database) o del backup della macchina virtuale. Gli strumenti di backup dei file leggono il database in modo sequenziale e ciò può richiedere parecchio tempo, soprattutto nel caso di database di grandi dimensioni, quindi è impossibile garantire l’integrità della copia di backup creata.

Le macchine virtuali possono utilizzare i meccanismi degli snapshot e del Changed Block Tracking, ma è necessario sincronizzare le copie di backup create per ottenere una copia di backup del database coerente, poiché la copia di backup risulterà incoerente in presenza di qualsiasi operazione di scrittura attiva sul database nel momento in cui si raccolgono i blocchi modificati.

Per coloro che desiderano eseguire il backup dei propri database con l’ausilio di strumenti di backup di file o macchine virtuali, possiamo offrire due metodi:

1. arrestare completamente i servizi e i processi del DBMS in modo che non ci sia nulla nella cache,
2. utilizzare agenti e/o script che commutano il database in una modalità speciale che rende sicura la copia sequenziale del file del database. Ad esempio, esiste un meccanismo chiamato VSS writer per i database MSSQL. Su richiesta, commuta il database nella modalità compatibile con gli snapshot nel momento in cui viene creato uno snapshot. Se si utilizzano meccanismi basati sul Changed Block Tracking, bisogna assicurarsi personalmente che il database sia coerente al momento della sincronizzazione.

Se non si commuta il database nella modalità compatibile con il backup, la copia del database risultante apparirà come se sul computer host si fosse verificato un hard reset (ad esempio, un’interruzione di corrente). Questo livello di affidabilità è assolutamente insufficiente per la maggior parte delle aziende. È possibile approfondire l’argomento nell’articolo “Peculiarità del lavoro con i database sulle macchine virtuali”.

Per Firebird, è necessario bloccare il file principale del database con l’ausilio di nbackup prima dell’avvio del processo di backup e sbloccarlo al termine del processo. Per altri DBMS esistono strumenti simili per attivare/disattivare le modalità corrispondenti.

Alcuni amministratori di database sono convinti di poter eseguire tranquillamente il backup dei propri database con l’ausilio di strumenti di backup standard dei file se il DBMS dispone di un transaction log, poiché al massimo sarà corrotto solo questo log. Si tratta di un pericoloso fraintendimento che gli sviluppatori di DBMS non supportano.

Le radici di questo fraintendimento sono chiare: la pubblicità aggressiva degli sviluppatori di macchine virtuali e strumenti di backup di solito omette di menzionare che i database, così come altri file aggiornati intensivamente, richiedono una configurazione avanzata. Non credete alle mode - non tutti gli yogurt hanno gli stessi benefici.

Raccomandazioni: non utilizzare strumenti di backup di file e VM senza i corrispondenti strumenti di automazione per i database.

Raccomandazione per Firebird: utilizzare FBDataGuard (dal pacchetto di distribuzione HQbird), che fornisce l’integrazione con strumenti di backup compatibili con VSS.

12. Sostituire il backup con la replica

Il backup dei dati e la replica dei dati vengono utilizzati per aumentare l’affidabilità e prevenire la perdita di dati, ma restano comunque piuttosto diversi.

Tutti amano la replica per la capacità di sincronizzare i dati su un altro server con il minimo ritardo, ma anche il backup ha alcuni indiscutibili vantaggi. Ad esempio, in caso di cancellazione accidentale (o intenzionale) dei dati, la replica invierà rapidamente e imperturbabilmente le modifiche alla replica, mentre il backup (soprattutto con copie su supporti di sola lettura) è immune a tali operazioni. Configurare correttamente sia la replica che il backup richiede un certo sforzo e la possibilità di errori esiste comunque.

Raccomandazioni: se avete configurato la replica, non trascurate le copie di backup, utilizzate entrambe.

Raccomandazione per Firebird: utilizzare il pacchetto di distribuzione HQbird Enterprise, che include sia strumenti di backup che di replica.

Riepilogo

Non è così semplice configurare il backup per il proprio DBMS preferito, quindi di solito gli amministratori di database delle organizzazioni in cui tengono ai propri dati utilizzano strumenti di backup professionali che consentono di tenere conto dei problemi sopra menzionati e prevenire i problemi.

Per Firebird (chiedo scusa per la pubblicità) esiste un pacchetto chiamato HQbird che include FBDataGuard.

Inoltre, la nostra azienda fornisce supporto completo per backup e manutenzione per Firebird e altri database, questa è una buona scelta per coloro che non sono a conoscenza di tutti i dettagli tecnici dei backup.

E, naturalmente, continuate a coltivare la vostra paranoia da amministratori, ad esempio, alzatevi e controllate le vostre copie di backup proprio adesso :)

Contatti

Non esitate a porre qualsiasi domanda: [email protected]

Volete ricevere notizie e articoli su Firebird? Unitevi a noi su Telegram https://t.me/firebirdsql