Questo errore è più comune tra i neofiti che non si rendono conto che lo scopo principale di una copia di backup del database non è solo quello di creare una copia del database, ma di abbreviare i tempi di inattività di un sistema informativo (una parte importante del quale è il database) il più possibile.
Di conseguenza, il sistema rimane non protetto dal momento in cui l'ultima copia di backup viene eliminata e al momento in cui viene creata la nuova copia poiché il database non ha una singola copia di backup durante questo periodo. Poiché la creazione di una copia di backup può richiedere del tempo, è il momento perfetto per rendere effettiva la legge di Murphy. Questo approccio funziona particolarmente bene quando è combinato con il numero 7 (vedi sotto).
Consigli: non eliminare la copia di backup precedente prima di crearne una nuova! (e non creare una nuova copia di backup in un file esistente).
Raccomandazione per Firebird: esiste uno strumento FBDataGuard incluso in HQbird (un pacchetto di distribuzione avanzata di Firebird) che elimina la prima copia di backup nella cronologia solo dopo averne creata una nuova.
Questo errore è meno comune sebbene i risultati possano essere molto peggiori. Se la copia di backup non è stata verificata e risulta danneggiata (consultare il problema 6), non si avrà né la copia precedente del database né una copia di backup valida.
Un pasticcio come questo di solito accade un venerdì sera quando le cose si fanno frenetiche e quando le indicazioni della direzione diventano contraddittorie. Un po 'di sfortuna e un languido weekend nella sala server sono lì per te.
Firebird ha un certo tipo di protezione contro questo errore: non sarà possibile ripristinare un database da una copia di backup con l'aiuto dell'utilità gbak se è attivata l'opzione di creazione predefinita e se il nome file specificato punta a un database esistente. Sfortunatamente, esiste un modo per aggirare questa protezione: l'opzione –rep consente comunque di sovrascrivere il file esistente.
Raccomandazione: non sovrascrivere mai il file di un database funzionante senza una direttiva scritta da parte della direzione.
Raccomandazione per Firebird: utilizzare FBDataGuard perché non sovrascrive mai il file di database.
I flussi di input / output standard consentono di fare un trucco divertente con molti DBMS (incluso Firebird): implementare un backup in streaming con il ripristino del database da esso contemporaneamente. Di conseguenza, non viene creato alcun file di backup intermedio. È utile 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 è necessario utilizzarla per il backup automatico!
Ad esempio, se si verifica un grave errore del disco durante questo processo di backup / ripristino, il database iniziale potrebbe danneggiarsi mentre non è stato ancora creato un nuovo database. Naturalmente, se si tiene conto del problema 1 e esiste una copia del database del tentativo precedente, verranno persi solo i dati creati o aggiornati nel database dopo la creazione di tale copia.
Consigli: non utilizzare il backup / ripristino in una sola fase in modalità automatica e verificare sempre la disponibilità di una copia sufficientemente aggiornata in modalità manuale.
Molti di voi potrebbero trovare divertente che il consiglio che diamo sia un po 'infantile: l'ABC del backup. Esatto, è vero, ma il database e il disco potrebbero finire per essere archiviati su un sistema di archiviazione dati a causa della popolarità degli ambienti virtuali. E certamente fallirà nel momento più inappropriato. Inoltre ci sono ancora persone che credono che non possa accadere nulla con i loro dati se usano array RAID (versione 1 o successiva :)). Inoltre, ci sono persone che credono che alcuni server "di marca" siano a prova di errore, ma questo è un caso speciale.
Consigli: non archiviare copie di backup e il database su un dispositivo, non importa quanto possa sembrare affidabile.
È un errore piuttosto comune tra gli amministratori e i responsabili dei dipartimenti IT. Se non si verificano i risultati del processo di backup, è possibile che non si esegua affatto. È necessario ricevere notifiche sul processo di backup completato correttamente tramite e-mail o, ancora meglio, anche tramite SMS. E l'assenza di tali notifiche è un segno di un problema!
Un lettore attento che ha raggiunto questo punto nel nostro articolo (anche se è troppo presto per dare un premio per quello finora) può chiedere: "Ma cosa c'entra il management?" 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 ulteriori rapporti sullo stato del processo. Riguarda la questione di chi è la colpa quando sembra che ci fossero copie di backup, ma in realtà non ci sono nel momento in cui ne hai bisogno :)
! una volta combinato con il numero 2, non abbiamo né il database né la sua copia di backup.
Consigli: utilizzare strumenti di automazione del backup in grado di monitorare processi di backup riusciti e non riusciti, informare gli utenti sui problemi e offrire strumenti di controllo riepilogativi (è particolarmente rilevante quando è necessario controllare dozzine 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 visualizzare gli stati di tutti i server e database monitorati su un'unica pagina.
Il fatto che le copie di backup siano archiviate da qualche parte non significa che possano essere lette da lì.
Questo è il motivo per cui è necessario verificare regolarmente le copie di backup create per assicurarsi che non siano danneggiate o copiate in / dev / null.
Raccomandazione per Firebird: è possibile automatizzare la convalida del backup con l'aiuto di FBDataGuard.
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, è gbak e nbackup.
Gbak legge l'intero database a livello di record per creare un file di backup e crea un database inserendo i record in un nuovo database verificando così la copia di backup (ci sono modi per errori di intrufolarsi nella copia ripristinata, ma questo è un altro modo per l'amministratore del database di confondere le cose relative alla migrazione mal organizzata) e il database stesso (se può essere letto dall'inizio alla fine, molto probabilmente non è danneggiato).
Nbackup (noto anche come backup incrementale) blocca temporaneamente il file di database principale per gli aggiornamenti (nello stato coerente) e consente di copiare rapidamente il file di database (completamente o parzialmente / in modo incrementale).
Nel caso di database Firebird di grandi dimensioni (superiori a 500 GB), è consigliabile utilizzare nbackup per non rallentare le operazioni dell'utente, ma allo stesso tempo è necessario convalidare il database poiché 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 errore RAM) o a livello logico, una copia di backup non verificata conterrà sia il database originale.
Per evitarlo, è necessario utilizzare la convalida online per il database originale (la convalida online con l'aiuto di gfix è disponibile a partire dalla versione 2.5.4 di Firebird, mentre il nostro strumento FBDataGuard supporta la convalida del database online per le versioni 1.5-2.5).
Inoltre, è consigliabile eseguire il backup verificato una volta ogni tanto (una volta alla settimana, ad esempio) oltre 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.
In realtà, si tratta di un classico errore: se lo spazio non è sufficiente, le copie di backup occupano tutto lo spazio libero e il processo termina con un errore. L'archiviazione di copie di backup su un disco con il database può comportare un'interruzione del funzionamento del database e la loro memorizzazione sul disco di sistema può causare un errore del sistema.
In combinazione con il numero 4, il miglior risultato possibile sarà quello in cui il sistema smette di funzionare perché anche il database ha bisogno di spazio libero, ma è occupato da copie di backup. Per quanto riguarda la combinazione con i problemi 5 e 2, non ci lascia di nuovo né il database né la sua copia di backup.
Consigli: utilizzare strumenti di backup che prevedono le dimensioni del backup e avvisano della possibile mancanza di spazio libero.
Raccomandazione per Firebird: FBDataGuard controlla la dimensione dello spazio libero a fini di backup e anche la dimensione dello spazio libero sul disco con database e sul disco di sistema.
Il processo di backup è durato 40 minuti letteralmente mezzo anno fa e poi all'improvviso ci vogliono già tre ore: perché? Le dimensioni del database potrebbero essere aumentate o un disco potrebbe essere uscito dall'array RAID con conseguenti prestazioni di scrittura notevolmente più lente e tutte le copie di backup potrebbero essere in procinto di partire da questo mondo. Oppure un tuo buon collega potrebbe aver eseguito un altro sistema di backup contemporaneamente (a proposito, Firebird ti consente di eseguire diversi processi di backup contemporaneamente anche se non è del tutto chiaro il motivo per cui uno potrebbe averne bisogno). Se non controlli il tempo necessario per eseguire una copia di backup, potresti trascurare un problema appena emerso e perdere l'occasione di risolverlo prima che diventi massiccio.
Inoltre, se il sistema di backup non monitora gli stati delle attività di backup e li esegue secondo la pianificazione, si può facilmente "saltare la pistola", il che significa la situazione in cui il sistema avvia un nuovo processo di backup mentre il precedente non è terminato ancora.
Consigli: utilizzare strumenti che controllano il tempo impiegato dal processo di backup!
Raccomandazione per Firebird: FBDataGuard controlla il tempo impiegato dal processo di backup.
È un problema molto comune soprattutto in combinazione con il numero 9 e gli aggiornamenti automatici di Windows abilitati (per impostazione predefinita, gli aggiornamenti vengono applicati alle 3 del mattino). Ciò porta ad un rallentamento nella migliore delle ipotesi, ma se il sistema operativo viene riavviato per applicare gli aggiornamenti, la copia di backup verrà danneggiata. Almeno, la buona notizia è che il sistema operativo non viene aggiornato ogni giorno.
Consigli: pianificare gli aggiornamenti del sistema operativo quando non interferiscono con il processo di backup.
Molti amministratori dimenticano che qualsiasi DBMS ha una cache attiva e complessa che contiene dati letti e scritti mentre i file di database stessi vengono aperti in modalità di accesso casuale. Questo è il motivo per cui è necessario utilizzare tipi di backup speciali anziché il semplice backup di file (inclusa solo la copia di file di database) o il backup della macchina virtuale. Gli strumenti di backup dei file leggono il database in sequenza e potrebbe richiedere parecchio tempo, specialmente nel caso di database di grandi dimensioni, quindi è impossibile garantire l'integrità della copia di backup creata.
Le macchine virtuali possono utilizzare i meccanismi di snapshot e Tracking dei blocchi modificati, ma è necessario sincronizzare le copie di backup create per ottenere una copia di backup del database coerente poiché la copia di backup sarà incoerente in caso di operazioni di scrittura attive con il database in il momento dell'ordinamento della raccolta di blocchi modificati.
Per coloro che desiderano eseguire il backup dei propri database con l'aiuto di strumenti di backup di file o macchine virtuali, possiamo offrire due metodi:
arrestare completamente i servizi e i processi DBMS in modo che non ci sia nulla nella cache,
utilizzare agenti e / o script che commutano il database in una modalità speciale che rende sicuro copiare il file del database in sequenza. Ad esempio, esiste un meccanismo chiamato VSS writer per database MSSQL. Su richiesta, passa al database in modalità compatibile con lo snapshot nel momento in cui viene creato uno snapshot. Se si utilizzano meccanismi basati sul rilevamento dei blocchi modificati, è necessario assicurarsi che il database sia coerente al momento della sincronizzazione.
Se non si commuta il database in modalità di backup, la copia del database risultante sembrerà come se sul computer host si verificasse un hard reset (ad esempio un'interruzione dell'alimentazione). Questo livello di affidabilità è assolutamente insufficiente per la maggior parte delle aziende. Puoi saperne di più su questo nell'articolo "Peculiarità di lavorare con database su macchine virtuali".
Per Firebird, è necessario bloccare il file principale del database con l'aiuto 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 sicuri di poter eseguire il backup sicuro dei propri database con l'aiuto di strumenti di backup di file standard se il DBMS ha un registro delle transazioni perché solo questo registro sarà danneggiato al massimo. È un malinteso pericoloso che gli sviluppatori DBMS non supportano.
Le radici di questo malinteso sono chiare: la pubblicità aggressiva degli sviluppatori di macchine virtuali e strumenti di backup di solito non menziona il fatto che database e altri file intensamente aggiornati richiedono una configurazione avanzata. Non credere all'hype - non tutti gli yogurt hanno uguali benefici.
Consigli: non utilizzare strumenti di backup di file e VM senza gli strumenti di automazione corrispondenti per i database.
Raccomandazione per Firebird: utilizzare FBDataGuard (dal pacchetto di distribuzione HQbird), fornisce l'integrazione con strumenti di backup compatibili con VSS.
Il backup e la replica dei dati vengono utilizzati per aumentare l'affidabilità e prevenire la perdita di dati, ma sono comunque abbastanza diversi.
Tutti amano la replica per la possibilità di sincronizzare i dati su un altro server con il minimo ritardo, ma anche il backup presenta alcuni vantaggi indiscussi. Ad esempio, in caso di cancellazione accidentale (o intenzionale) dei dati, la replica invierà rapidamente e imperturbabilmente le modifiche alla replica mentre il backup (specialmente con copie su supporti di sola lettura) è immune da tali operazioni. Ci vuole un certo sforzo per configurare correttamente sia la replica che il backup e esiste comunque la possibilità di errori.
Consigli: se è stata configurata la replica, non trascurare le copie di backup, utilizzare entrambe.
Raccomandazione per Firebird: utilizzare il pacchetto di distribuzione HQbird Enterprise, che include strumenti di backup e replica.
