12 häufige Fehler bei der Sicherung von Datenbanken

von Alexey Kovyazin, 11. November 2015

PDF herunterladen (Englisch) Dieser Artikel war ursprünglich für Entwickler und Administratoren des Firebird-DBMS gedacht, aber Kontakte mit Administratoren anderer Datenbanken haben deutlich gemacht, dass die meisten Fehler auch dort üblich sind und buchstäblich jeder über fast dieselben Steine stolpert. Wenn Sie etwas zu dieser Liste hinzufügen können (auch etwas, das für ein bestimmtes DBMS spezifisch ist), kontaktieren Sie uns per E-Mail unter [email protected].

1. Löschen der vorherigen Sicherungskopie, bevor eine neue Sicherungskopie erstellt wird

Dieser Fehler ist bei Neulingen am häufigsten, die nicht erkennen, dass der Hauptzweck einer Datenbanksicherungskopie nicht nur darin besteht, eine Kopie der Datenbank zu erstellen, sondern die Ausfallzeit eines Informationssystems (zu dem die Datenbank einen wichtigen Teil beiträgt) so kurz wie möglich zu halten.

Infolgedessen bleibt das System von dem Moment an, in dem die letzte Sicherungskopie gelöscht wird, bis zu dem Moment, in dem die neue erstellt wird, ungeschützt, da die Datenbank in diesem Zeitraum über keine einzige Sicherungskopie verfügt. Da das Erstellen einer Sicherungskopie einige Zeit in Anspruch nehmen kann, ist dies der perfekte Zeitpunkt für das Murphysche Gesetz. Dieser Ansatz funktioniert besonders gut, wenn er mit Problem 7 (siehe unten) kombiniert wird.

Empfehlungen: Löschen Sie die vorherige Sicherungskopie erst, wenn die neue erstellt wurde! (und erstellen Sie keine neue Sicherungskopie in eine vorhandene Datei).

Empfehlung für Firebird: Es gibt ein FBDataGuard-Tool, das in HQbird (einem erweiterten Distributionspaket von Firebird) enthalten ist und die älteste Sicherungskopie im Verlauf erst löscht, nachdem eine neue erstellt wurde.

2. Überschreiben einer vorhandenen Datenbank beim Wiederherstellen aus einer Sicherungskopie

Dieser Fehler ist weniger häufig, obwohl die Ergebnisse viel schlimmer sein können. Wenn die Sicherungskopie nicht verifiziert wurde und sich als beschädigt herausstellt (siehe Problem 6), haben Sie weder die vorherige Kopie der Datenbank noch eine gültige Sicherungskopie.

Ein solches Durcheinander passiert normalerweise an einem Freitagabend, wenn es hektisch zugeht und die Anweisungen des Managements widersprüchlich werden. Ein wenig Pech und ein träges Wochenende im Serverraum sind Ihnen sicher.

Firebird verfügt über eine Art Schutz gegen diesen Fehler - es ist nicht möglich, eine Datenbank aus einer Sicherungskopie mit Hilfe des gbak-Dienstprogramms wiederherzustellen, wenn dessen Standard-Schalter -create aktiviert ist und der angegebene Dateiname auf eine vorhandene Datenbank verweist. Leider gibt es einen Weg, diesen Schutz zu umgehen: Der -rep-Schalter erlaubt weiterhin das Überschreiben der vorhandenen Datei.

Empfehlung: Überschreiben Sie niemals die Datei einer laufenden Datenbank ohne eine schriftliche Anweisung Ihres Managements.

Empfehlung für Firebird: Verwenden Sie FBDataGuard, da es die Datenbankdatei niemals überschreibt.

3. Verwendung von einstufigem Backup/Wiederherstellung ohne Zwischensicherungsdatei

Standard-Eingabe-/Ausgabeströme ermöglichen einen lustigen Trick bei vielen DBMS (einschließlich Firebird): die Implementierung eines Streaming-Backups mit sofortiger Wiederherstellung der Datenbank daraus. Es wird keine Zwischensicherungsdatei erstellt. Dies ist praktisch für routinemäßige Wartungsarbeiten und für die Durchführung eines Test-Wiederherstellungsvorgangs (sofern eine andere Sicherungskopie verfügbar ist), aber Sie dürfen es nicht für automatische Sicherungen verwenden!

Wenn beispielsweise während dieses Backup-/Wiederherstellungsprozesses ein schwerwiegender Festplattenfehler auftritt, kann die ursprüngliche Datenbank beschädigt werden, während noch keine neue Datenbank erstellt wurde. Wenn Sie natürlich Problem 1 berücksichtigen und eine Datenbankkopie vom vorherigen Versuch vorhanden ist, gehen nur die Daten verloren, die nach der Erstellung dieser Kopie in der Datenbank erstellt oder aktualisiert wurden.

Empfehlungen: Verwenden Sie einstufiges Backup/Wiederherstellung nicht im automatischen Modus und überprüfen Sie im manuellen Modus immer die Verfügbarkeit einer ausreichend aktuellen Kopie.

4. Speichern von Sicherungskopien und Datenbank auf demselben physischen Gerät

Viele von Ihnen finden es vielleicht amüsant, dass unser Rat irgendwie kindisch ist - das ABC der Sicherung. Ja, das stimmt, aber aufgrund der Beliebtheit virtueller Umgebungen können die Datenbank und die Festplatte in einem einzigen Datenspeichersystem gespeichert werden. Und es wird sicherlich im unpassendsten Moment ausfallen. Außerdem gibt es immer noch Menschen, die glauben, dass mit ihren Daten nichts passieren kann, wenn sie RAID-Arrays verwenden (Version 1 oder höher :)). Darüber hinaus gibt es Menschen, die glauben, dass bestimmte “Marken”-Server unfehlbar sind, aber das ist ein Sonderfall.

Empfehlungen: Speichern Sie Sicherungskopien und Datenbank nicht auf einem Gerät, egal wie zuverlässig es erscheinen mag.

5. Keine Kontrolle über den erfolgreichen Abschluss des Sicherungsprozesses

Dies ist ein ziemlich häufiger Fehler sowohl bei Administratoren als auch bei IT-Abteilungsleitern. Wenn Sie die Ergebnisse des Sicherungsprozesses nicht überprüfen, können Sie ihn auch ganz weglassen. Sie müssen Benachrichtigungen über den erfolgreich abgeschlossenen Sicherungsprozess per E-Mail oder, noch besser, auch per SMS erhalten. Und das Fehlen solcher Benachrichtigungen ist ein Zeichen für ein Problem!

Ein aufmerksamer Leser, der diesen Punkt in unserem Artikel erreicht hat (obwohl es noch zu früh ist, einen Preis dafür zu vergeben), könnte fragen: ‘Aber was hat das mit dem Management zu tun?’ Hier ist die Antwort: Der Administrator konfiguriert normalerweise den Sicherungsprozess, findet es aber zu langweilig, Benachrichtigungen zu überprüfen, besonders wenn sie in einem separaten Ordner gespeichert werden. Daher ist es nie verkehrt, zusätzliche Berichte über den Status des Prozesses anzufordern. Es geht um die Frage, wer schuld ist, wenn es so aussieht, als wären Sicherungskopien vorhanden, aber sie tatsächlich nicht da sind, wenn man sie braucht :)

! In Kombination mit Problem 2 haben wir weder die Datenbank noch ihre Sicherungskopie.

Empfehlungen: Verwenden Sie Backup-Automatisierungswerkzeuge, die erfolgreiche und fehlgeschlagene Sicherungsprozesse überwachen, Benutzer über Probleme informieren und zusammenfassende Kontrollwerkzeuge anbieten können (besonders relevant, wenn Sie Dutzende und Hunderte von Sicherungsprozessen auf verschiedenen Servern kontrollieren müssen).

Empfehlung für Firebird: FBDataGuard prüft, ob der Sicherungsprozess abgeschlossen wurde, und sendet die entsprechende Benachrichtigung. Für Systeme mit vielen Datenbanken gibt es eine übergeordnete Zusammenfassungsüberwachung mit Hilfe des Control Center-Tools, mit dem Sie die Status aller überwachten Server und Datenbanken auf einer Seite sehen können.

6. Keine Validierung der Sicherungskopien

Die Tatsache, dass Sicherungskopien irgendwo gespeichert sind, bedeutet nicht, dass sie von dort gelesen werden können.

Deshalb müssen Sie die von Ihnen erstellten Sicherungskopien regelmäßig verifizieren, um sicherzustellen, dass sie nicht beschädigt oder nach /dev/null kopiert wurden.

Empfehlung für Firebird: Sie können die Sicherungsvalidierung mit Hilfe von FBDataGuard automatisieren.

7. Keine Datenbank-Gesundheitsprüfungen bei Verwendung unverifizierter Sicherungskopien

Normalerweise verwenden Datenbanken mehrere Arten von Sicherungen - Dumps, reguläre Sicherungskopien usw. Ohne ins Detail zu gehen, können wir zwei Kategorien unterscheiden: verifizierte und unverifizierte. Im Fall von Firebird sind dies gbak und nbackup.

Gbak liest die gesamte Datenbank auf Datensatzebene, um eine Sicherungsdatei zu erstellen, und erstellt eine Datenbank durch Einfügen von Datensätzen in eine neue Datenbank, wodurch sowohl die Sicherungskopie (es gibt Möglichkeiten, dass Fehler in die wiederhergestellte Kopie gelangen, aber das ist ein anderer Weg, wie der Datenbankadministrator Dinge vermasseln kann, der mit schlecht organisierter Migration zusammenhängt) als auch die Datenbank selbst verifiziert werden (wenn sie von Anfang bis Ende gelesen werden kann, ist sie höchstwahrscheinlich nicht beschädigt).

Nbackup (auch bekannt als inkrementelle Sicherung) sperrt die Hauptdatenbankdatei vorübergehend für Aktualisierungen (im konsistenten Zustand) und ermöglicht das schnelle Kopieren der Datenbankdatei (vollständig oder teilweise/inkrementell).

Bei großen Firebird-Datenbanken (größer als 500 GB) ist es ratsam, nbackup zu verwenden, um Benutzeroperationen nicht zu verlangsamen, aber gleichzeitig ist es notwendig, die Datenbank zu validieren, da die von ihr erstellten unverifizierten Sicherungskopien Kopien von Datenbankseiten sind. Wenn ein Fehler auf Datensatzebene (aufgrund eines RAM-Ausfalls) oder auf logischer Ebene vorliegt, enthält eine unverifizierte Sicherungskopie ihn ebenso wie die ursprüngliche Datenbank.

Um dies zu vermeiden, sollten Sie die Online-Validierung für die ursprüngliche Datenbank verwenden (Online-Validierung mit Hilfe von gfix ist ab Firebird Version 2.5.4 verfügbar, während unser FBDataGuard-Tool die Online-Datenbankvalidierung für die Versionen 1.5-2.5 unterstützt).

Außerdem ist es ratsam, zusätzlich zur unverifizierten Sicherung gelegentlich eine verifizierte Sicherung durchzuführen (zum Beispiel einmal pro Woche).

Empfehlung für Firebird: Neben der Online-Gesundheitsprüfung ermöglicht FBDataGuard das Testen des Wiederherstellungsprozesses im automatischen Modus.

8. Keine Kontrolle über den freien Speicherplatz für Sicherungskopien

Eigentlich ist es ein klassischer Fehler: Wenn nicht genügend Speicherplatz vorhanden ist, belegen Sicherungskopien den gesamten freien Speicherplatz und der Prozess endet mit einem Fehler. Das Speichern von Sicherungskopien auf derselben Festplatte wie die Datenbank kann zu einer Unterbrechung des Datenbankbetriebs führen, und das Speichern auf der Systemfestplatte kann zu einem Systemausfall führen.

In Kombination mit Problem 4 ist das bestmögliche Ergebnis, dass das System aufhört zu funktionieren, weil die Datenbank ebenfalls freien Speicherplatz benötigt, dieser aber von Sicherungskopien belegt ist. Was Kombinationen mit den Problemen 5 und 2 betrifft, bleiben wir wieder ohne Datenbank und ohne Sicherungskopie zurück.

Empfehlungen: Verwenden Sie Sicherungswerkzeuge, die die Sicherungsgröße vorhersagen und Sie vor möglichem Speicherplatzmangel warnen.

Empfehlung für Firebird: FBDataGuard kontrolliert die Größe des freien Speicherplatzes für Sicherungszwecke sowie die Größe des freien Speicherplatzes auf der Festplatte mit den Datenbanken und auf der Systemfestplatte.

9. Keine Kontrolle über die Zeit, die zum Erstellen einer Sicherungskopie benötigt wird

Der Sicherungsprozess dauerte vor einem halben Jahr buchstäblich 40 Minuten und plötzlich dauert er schon drei Stunden - warum? Die Größe der Datenbank kann zugenommen haben, oder eine Festplatte aus Ihrem RAID-Array kann ausgefallen sein, was zu erheblich langsamerer Schreibleistung führt, und alle Ihre Sicherungskopien könnten kurz davor sein, diese Welt zu verlassen. Oder ein guter Kollege von Ihnen hat gleichzeitig ein weiteres Sicherungssystem gestartet (übrigens erlaubt Firebird das gleichzeitige Ausführen mehrerer Sicherungsprozesse, obwohl nicht ganz klar ist, warum man das überhaupt braucht). Wenn Sie die Zeit für die Erstellung einer Sicherungskopie nicht kontrollieren, können Sie ein neu aufgetretenes Problem übersehen und die Chance verpassen, es zu beheben, bevor es sich ausweitet.

Wenn das Sicherungssystem außerdem die Status von Sicherungsaufgaben nicht überwacht und sie nur nach Zeitplan ausführt, können Sie leicht “vorgreifen”, was die Situation bedeutet, in der das System einen neuen Sicherungsprozess startet, während der vorherige noch nicht beendet ist.

Empfehlungen: Verwenden Sie Werkzeuge, die die Zeit des Sicherungsprozesses kontrollieren!

Empfehlung für Firebird: FBDataGuard kontrolliert die Zeit, die der Sicherungsprozess benötigt.

10. Sicherung der Datenbank während der Anwendung von Betriebssystem-Updates

Dies ist ein sehr häufiges Problem, besonders in Kombination mit Problem 9 und aktivierten automatischen Windows-Updates (standardmäßig werden Updates um 3 Uhr morgens angewendet). Es führt bestenfalls zu einer Verlangsamung, aber wenn das Betriebssystem neu gestartet wird, um die Updates anzuwenden, wird die Sicherungskopie beschädigt. Zumindest ist die gute Nachricht, dass das Betriebssystem nicht jeden Tag aktualisiert wird.

Empfehlungen: Planen Sie Betriebssystem-Updates so, dass sie nicht mit dem Sicherungsprozess kollidieren.

11. Sicherung der Datenbank mit Dateisicherungswerkzeugen oder Werkzeugen zur Sicherung virtueller Maschinen, während der Datenbankserver läuft

Viele Administratoren vergessen, dass jedes DBMS einen aktiven und komplexen Cache hat, der gelesene und geschriebene Daten enthält, während die Datenbankdateien selbst im Direktzugriffsmodus geöffnet sind. Deshalb ist es notwendig, spezielle Sicherungsarten zu verwenden, anstatt nur Dateisicherungen (einschließlich des bloßen Kopierens von Datenbankdateien) oder die Sicherung virtueller Maschinen durchzuführen. Dateisicherungswerkzeuge lesen die Datenbank sequenziell, was besonders bei großen Datenbanken ziemlich lange dauern kann, sodass die Integrität der erstellten Sicherungskopie nicht garantiert werden kann.

Virtuelle Maschinen können die Mechanismen von Snapshots und Changed Block Tracking nutzen, aber es ist notwendig, die erstellten Sicherungskopien zu synchronisieren, um eine konsistente Datenbank-Sicherungskopie zu erhalten, da die Sicherungskopie bei aktiven Schreiboperationen mit der Datenbank zum Zeitpunkt der Zusammenstellung der geänderten Blöcke inkonsistent sein wird.

Für diejenigen, die ihre Datenbanken mit Hilfe von Datei- oder VM-Sicherungswerkzeugen sichern möchten, bieten wir zwei Methoden an:

1. DBMS-Dienste und -Prozesse vollständig herunterfahren, damit nichts im Cache ist,
2. Agenten und/oder Skripte verwenden, die die Datenbank in einen speziellen Modus versetzen, der das sichere sequenzielle Kopieren der Datenbankdatei ermöglicht. Beispielsweise gibt es für MSSQL-Datenbanken einen Mechanismus namens VSS Writer. Auf Anforderung versetzt er die Datenbank zum Zeitpunkt der Snapshot-Erstellung in den snapshot-freundlichen Modus. Wenn Sie Mechanismen verwenden, die auf Changed Block Tracking basieren, müssen Sie selbst sicherstellen, dass die Datenbank zum Zeitpunkt der Synchronisierung konsistent ist.

Wenn Sie die Datenbank nicht in den backup-freundlichen Modus versetzen, sieht die resultierende Datenbankkopie so aus, als ob ein harter Reset (z. B. ein Stromausfall) auf dem Host-Computer stattgefunden hätte. Dieses Maß an Zuverlässigkeit ist für die meisten Unternehmen absolut unzureichend. Mehr dazu erfahren Sie im Artikel „Besonderheiten der Arbeit mit Datenbanken auf virtuellen Maschinen“.

Für Firebird ist es notwendig, die Hauptdatei der Datenbank vor dem Start des Sicherungsprozesses mit Hilfe von nbackup zu sperren und nach Abschluss des Prozesses wieder zu entsperren. Für andere DBMS gibt es ähnliche Werkzeuge zum Ein- und Ausschalten der entsprechenden Modi.

Einige Datenbankadministratoren sind sich sicher, dass sie ihre Datenbanken sicher mit Standard-Dateisicherungswerkzeugen sichern können, wenn das DBMS über ein Transaktionsprotokoll verfügt, da höchstens nur dieses Protokoll beschädigt wird. Dies ist eine gefährliche Fehlannahme, die von den DBMS-Entwicklern nicht unterstützt wird.

Die Wurzeln dieser Fehlannahme sind klar: Aggressive Werbung der Entwickler von virtuellen Maschinen und Sicherungswerkzeugen erwähnt in der Regel nicht, dass Datenbanken sowie andere intensiv aktualisierte Dateien eine erweiterte Konfiguration erfordern. Glauben Sie nicht dem Hype - nicht alle Joghurts haben gleiche Vorteile.

Empfehlungen: Verwenden Sie keine Datei- und VM-Sicherungswerkzeuge ohne die entsprechenden Automatisierungswerkzeuge für Datenbanken.

Empfehlung für Firebird: Verwenden Sie FBDataGuard (aus dem HQbird-Verteilungspaket), es bietet Integration mit VSS-fähigen Sicherungswerkzeugen.

12. Ersetzen von Backup durch Replikation

Datensicherung und Datenreplikation werden verwendet, um die Zuverlässigkeit zu erhöhen und Datenverluste zu verhindern, aber sie sind dennoch recht unterschiedlich.

Jeder liebt Replikation für die Fähigkeit, Daten auf einem anderen Server mit minimaler Verzögerung zu synchronisieren, aber Backup hat auch einige unbestrittene Vorteile. Beispielsweise wird bei versehentlichem (oder absichtlichem) Löschen von Daten die Replikation die Änderungen schnell und unerschütterlich an die Replik senden, während Backup (insbesondere mit Kopien auf schreibgeschützten Medien) gegen solche Operationen immun ist. Es erfordert gewisse Anstrengungen, sowohl Replikation als auch Backup korrekt zu konfigurieren, und dennoch besteht immer die Möglichkeit von Fehlern.

Empfehlungen: Wenn Sie Replikation konfiguriert haben, vernachlässigen Sie keine Sicherungskopien, verwenden Sie beides.

Empfehlung für Firebird: Verwenden Sie das HQbird Enterprise-Verteilungspaket, es enthält sowohl Backup- als auch Replikationswerkzeuge.

Zusammenfassung

Es ist nicht so einfach, Backup für Ihr bevorzugtes DBMS zu konfigurieren, daher verwenden Datenbankadministratoren aus Organisationen, die ihre Daten schätzen, in der Regel professionelle Sicherungswerkzeuge, die es ermöglichen, die oben genannten Probleme zu berücksichtigen und Probleme zu verhindern.

Für Firebird (Verzeihung für die Werbung) gibt es ein Paket namens HQbird, das FBDataGuard enthält.

Darüber hinaus bietet unser Unternehmen vollständigen Backup- und Wartungssupport für Firebird und andere Datenbanken an. Dies ist eine gute Wahl für diejenigen, die nicht alle technischen Details von Backups kennen.

Und natürlich: Pflegen Sie weiterhin Ihre Admin-Paranoid, zum Beispiel stehen Sie auf und überprüfen Sie Ihre Sicherungskopien noch jetzt :)

Kontakte

Zögern Sie nicht, Fragen zu stellen: [email protected]

Möchten Sie Neuigkeiten und Artikel über Firebird erhalten? Treten Sie uns in Telegram bei https://t.me/firebirdsql