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 Firebird-DBMS-Entwickler und -Administratoren gedacht, aber Kontakte mit Administratoren anderer Datenbanken machten deutlich, dass die meisten Fehler auch bei ihnen verbreitet sind und buchstäblich jeder über nahezu 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 [email protected].

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

Dieser Fehler ist am häufigsten unter Neulingen anzutreffen, die nicht erkennen, dass der Hauptzweck einer Datenbank-Sicherungskopie nicht nur darin besteht, eine Datenbankkopie zu erstellen, sondern die Ausfallzeit eines Informationssystems (zu dessen wichtigem Bestandteil die Datenbank gehört) 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 keine einzige Sicherungskopie besitzt. Da das Erstellen einer Sicherungskopie geraume Zeit in Anspruch nehmen kann, ist dies der perfekte Zeitpunkt für das Wirken von Murphys Gesetz. Dieser Ansatz funktioniert besonders gut in Kombination mit Problem 7 (siehe unten).

Empfehlungen: Löschen Sie die vorherige Sicherungskopie nicht, bevor die neue erstellt ist! (und erstellen Sie keine neue Sicherungskopie in eine bereits vorhandene Datei).

Empfehlung für Firebird: Es gibt ein Tool FBDataGuard, das in HQbird (einem erweiterten Distributionspaket von Firebird) enthalten ist und die früheste 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 verbreitet, obwohl die Folgen deutlich schlimmer sein können. Wenn die Sicherungskopie nicht überprüft wurde und sich als beschädigt erweist (siehe Problem 6), haben Sie weder die vorherige Kopie der Datenbank noch eine gültige Sicherungskopie.

Ein solches Chaos passiert gewöhnlich an einem Freitagabend, wenn es hektisch wird und die Anweisungen der Geschäftsleitung einigermaßen widersprüchlich sind. Etwas Pech, und ein langwieriges Wochenende im Serverraum steht Ihnen bevor.

Firebird hat eine Art Schutz gegen diesen Fehler – es ist nicht möglich, eine Datenbank mit dem Dienstprogramm gbak aus einer Sicherungskopie wiederherzustellen, wenn dessen Standard-Schalter -create aktiv ist und der angegebene Dateiname auf eine vorhandene Datenbank verweist. Leider gibt es einen Weg, diesen Schutz zu umgehen: Der Schalter -rep erlaubt es weiterhin, die vorhandene Datei zu überschreiben.

Empfehlung: Überschreiben Sie niemals die Datei einer laufenden Datenbank ohne eine schriftliche Anweisung Ihrer Geschäftsleitung.

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

3. Verwendung von Ein-Schritt-Backup/Restore ohne eine Zwischen-Sicherungsdatei

Standard-Ein-/Ausgabeströme ermöglichen bei vielen DBMS (einschließlich Firebird) einen lustigen Trick: ein Streaming-Backup mit sofortiger Wiederherstellung der Datenbank daraus zu realisieren. Dadurch wird keine Zwischen-Sicherungsdatei erstellt. Das ist praktisch für die Routinewartung und für die Durchführung eines Test-Wiederherstellungsvorgangs (vorausgesetzt, es ist eine weitere Sicherungskopie verfügbar), aber Sie dürfen es nicht für das automatische Backup verwenden!

Wenn beispielsweise während dieses Backup/Restore-Vorgangs 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 aus dem vorherigen Versuch vorhanden ist, gehen nur die Daten verloren, die nach dem Erstellen dieser Kopie in der Datenbank erstellt oder aktualisiert wurden.

Empfehlungen: Verwenden Sie Ein-Schritt-Backup/Restore nicht im automatischen Modus und prüfen Sie im manuellen Modus stets die Verfügbarkeit einer ausreichend aktuellen Kopie.

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

Viele von Ihnen mögen es amüsant finden, dass unser Rat irgendwie kindisch ist – das Einmaleins des Backups. Richtig, das stimmt, aber aufgrund der Beliebtheit virtueller Umgebungen können die Datenbank und die Festplatte am Ende auf ein und demselben Datenspeichersystem liegen. Und es wird sicherlich im unpassendsten Moment ausfallen. Außerdem gibt es noch immer Leute, die glauben, dass ihren Daten nichts passieren kann, wenn sie RAID-Arrays (Version 1 oder höher :) verwenden. Zudem gibt es Leute, die glauben, dass einige „Marken“-Server ausfallsicher sind, aber das ist ein Sonderfall.

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

5. Keine Kontrolle über den erfolgreichen Abschluss des Sicherungsvorgangs

Es ist ein ziemlich verbreiteter Fehler sowohl bei Administratoren als auch bei den Leitern von IT-Abteilungen. Wenn Sie die Ergebnisse des Sicherungsvorgangs nicht prüfen, können Sie ihn genauso gut gar nicht durchführen. Sie müssen Benachrichtigungen über den erfolgreich abgeschlossenen Sicherungsvorgang per E-Mail oder, noch besser, auch per SMS erhalten. Und das Ausbleiben solcher Benachrichtigungen ist ein Zeichen für ein Problem!

Ein aufmerksamer Leser, der bis zu diesem Punkt unseres Artikels gelangt ist (obwohl es noch zu früh ist, dafür einen Preis zu vergeben), mag fragen: „Aber was hat das mit der Geschäftsleitung zu tun?“ Folgendes – der Administrator konfiguriert normalerweise den Sicherungsvorgang, aber er findet es zu langweilig, Benachrichtigungen zu prüfen, besonders wenn sie in einem separaten Ordner gespeichert werden, daher kann man nie genug zusätzliche Berichte über den Status des Vorgangs anfordern. Das betrifft die Frage, wer schuld ist, wenn es so aussieht, als wären Sicherungskopien vorhanden, sie aber in dem Moment, in dem man sie braucht, tatsächlich nicht da sind :)

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

Empfehlungen: Verwenden Sie Backup-Automatisierungstools, die erfolgreiche und fehlgeschlagene Sicherungsvorgänge überwachen, Benutzer über Probleme benachrichtigen und zusammenfassende Kontrollwerkzeuge bieten (besonders relevant, wenn Sie Dutzende und Hunderte von Sicherungsvorgängen auf verschiedenen Servern kontrollieren müssen).

Empfehlung für Firebird: FBDataGuard prüft, ob der Sicherungsvorgang abgeschlossen wurde, und sendet die entsprechende Benachrichtigung. Für Systeme mit vielen Datenbanken gibt es eine zusammenfassende Überwachung auf zweiter Ebene mit Hilfe des Control Center-Tools, das es Ihnen ermöglicht, die Status aller überwachten Server und Datenbanken auf einer Seite zu sehen.

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 überprüfen, um sicherzustellen, dass sie nicht beschädigt oder nach /dev/null kopiert wurden.

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

7. Keine Zustandsprüfungen der Datenbank bei Verwendung ungeprüfter Sicherungskopien

Üblicherweise verwenden Datenbanken mehrere Sicherungsarten – Dumps, reguläre Sicherungskopien usw. Ohne ins Detail zu gehen, können wir zwei Kategorien unterscheiden: geprüfte und ungeprüfte. Im Fall von Firebird sind das gbak und nbackup.

Gbak liest die gesamte Datenbank auf der Ebene der Datensätze, um eine Sicherungsdatei zu erstellen, und erstellt eine Datenbank, indem es Datensätze in eine neue Datenbank einfügt, wodurch sowohl die Sicherungskopie (es gibt Wege, wie sich Fehler in die wiederhergestellte Kopie einschleichen können, aber das ist eine andere Art, wie der Datenbankadministrator im Zusammenhang mit schlecht organisierter Migration Dinge vermasseln kann) als auch die Datenbank selbst überprüft wird (wenn sie von Anfang bis Ende gelesen werden kann, ist sie höchstwahrscheinlich nicht beschädigt).

Nbackup (auch inkrementelles Backup genannt) sperrt die Hauptdatenbankdatei vorübergehend für Aktualisierungen (im konsistenten Zustand) und ermöglicht es, die Datenbankdatei schnell zu kopieren (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, denn die ungeprüften Sicherungskopien, die es erstellt, sind Kopien von Datenbankseiten, und wenn ein Fehler auf der Ebene der Datensätze (aufgrund eines RAM-Ausfalls) oder auf der logischen Ebene liegt, wird eine ungeprüfte Sicherungskopie ihn ebenso wie die Originaldatenbank enthalten.

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

Außerdem ist es ratsam, zusätzlich zum ungeprüften Backup gelegentlich (zum Beispiel einmal pro Woche) ein geprüftes Backup durchzuführen.

Empfehlung für Firebird: Neben der Online-Zustandsprüfung ermöglicht es FBDataGuard, den Wiederherstellungsvorgang der Sicherung im automatischen Modus zu testen.

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

Eigentlich ist es ein klassischer Fehler: Wenn nicht genügend Platz vorhanden ist, belegen Sicherungskopien den gesamten freien Speicherplatz und der Vorgang endet mit einem Fehler. Das Speichern von Sicherungskopien auf einer Festplatte zusammen mit der Datenbank kann zu einer Unterbrechung des Datenbankbetriebs führen, und das Speichern auf der Systemfestplatte kann einen Systemausfall zur Folge haben.

In Kombination mit Problem 4 wird das bestmögliche Ergebnis dasjenige sein, bei dem das System den Betrieb einstellt, weil auch die Datenbank freien Speicherplatz benötigt, dieser aber von Sicherungskopien belegt ist. Was die Kombination mit den Problemen 5 und 2 betrifft, bleiben uns wieder weder die Datenbank noch ihre Sicherungskopie.

Empfehlungen: Verwenden Sie Backup-Tools, die die Sicherungsgröße vorhersagen und Sie vor einem möglichen Mangel an freiem Speicherplatz 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 Sicherungsvorgang dauerte vor buchstäblich einem halben Jahr 40 Minuten, und plötzlich dauert er schon drei Stunden – warum ist das so? Die Größe der Datenbank kann zugenommen haben, oder eine Festplatte kann aus Ihrem RAID-Array ausgefallen sein, was zu einer erheblich langsameren Schreibleistung führt, und alle Ihre Sicherungskopien könnten kurz davor stehen, von dieser Welt zu scheiden. Oder ein guter Kollege von Ihnen hat gleichzeitig ein weiteres Sicherungssystem gestartet (Firebird erlaubt es übrigens, mehrere Sicherungsvorgänge gleichzeitig auszuführen, obwohl nicht ganz klar ist, warum man das überhaupt brauchen könnte). Wenn Sie die Zeit, die zum Erstellen einer Sicherungskopie benötigt wird, nicht kontrollieren, können Sie ein neu aufgetretenes Problem übersehen und die Gelegenheit verpassen, es zu beheben, bevor es massiv wird.

Wenn das Sicherungssystem außerdem die Status der Sicherungsaufgaben nicht überwacht und sie einfach nach Zeitplan ausführt, können Sie leicht „zu früh schießen“, was die Situation bedeutet, in der das System einen neuen Sicherungsvorgang startet, während der vorherige noch nicht beendet ist.

Empfehlungen: Verwenden Sie Tools, die die Zeit des Sicherungsvorgangs kontrollieren!

Empfehlung für Firebird: FBDataGuard kontrolliert die Zeit des Sicherungsvorgangs.

10. Sichern der Datenbank, während Betriebssystem-Updates angewendet werden

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

Empfehlungen: Planen Sie Betriebssystem-Updates so, dass sie den Sicherungsvorgang nicht beeinträchtigen.

11. Sichern der Datenbank mit Hilfe von Datei-Sicherungstools oder Tools zur Sicherung virtueller Maschinen, während der Datenbankserver läuft

Viele Administratoren vergessen, dass jedes DBMS einen aktiven und komplexen Cache besitzt, der Daten enthält, die gerade gelesen und geschrieben werden, während die Datenbankdateien selbst im Direktzugriffsmodus geöffnet sind. Deshalb ist es notwendig, spezielle Sicherungsarten anstelle der bloßen Dateisicherung (einschließlich des einfachen Kopierens von Datenbankdateien) oder der Sicherung virtueller Maschinen zu verwenden. Datei-Sicherungstools lesen die Datenbank sequenziell, und das kann geraume Zeit dauern, besonders bei großen Datenbanken, sodass es unmöglich ist, die Integrität der erstellten Sicherungskopie zu garantieren.

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, denn die Sicherungskopie wird inkonsistent sein, falls zum Zeitpunkt des Einsammelns der geänderten Blöcke aktive Schreibvorgänge auf die Datenbank stattfinden.

Für diejenigen, die ihre Datenbanken mit Hilfe von Datei- oder Virtual-Machine-Backup-Tools sichern möchten, können wir zwei Methoden anbieten:

1. DBMS-Dienste und -Prozesse vollständig herunterfahren, sodass sich nichts im Cache befindet,
2. Agenten und/oder Skripte verwenden, die die Datenbank in einen speziellen Modus versetzen, der es sicher macht, die Datenbankdatei sequenziell zu kopieren. Beispielsweise gibt es für MSSQL-Datenbanken einen Mechanismus namens VSS Writer. Auf Anforderung versetzt er die Datenbank in dem Moment, in dem ein Snapshot erstellt wird, in den snapshot-freundlichen Modus. Wenn Sie Mechanismen auf Basis von Changed Block Tracking verwenden, müssen Sie selbst dafür sorgen, dass die Datenbank zum Zeitpunkt der Synchronisierung konsistent ist.

Wenn Sie die Datenbank nicht in den backup-freundlichen Modus versetzen, wird die resultierende Datenbankkopie so aussehen, als wäre auf dem Host-Computer ein Hard Reset (zum Beispiel ein Stromausfall) aufgetreten. Dieses Zuverlässigkeitsniveau 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 mit Hilfe von nbackup zu sperren, bevor der Sicherungsprozess beginnt, und sie nach Abschluss des Prozesses zu entsperren. Für andere DBMS gibt es ähnliche Werkzeuge zum Ein- und Ausschalten der entsprechenden Modi.

Einige Datenbankadministratoren sind sicher, dass sie ihre Datenbanken mit Hilfe von Standard-Datei-Backup-Tools sicher sichern können, wenn das DBMS über ein Transaktionsprotokoll verfügt, da höchstens dieses Protokoll beschädigt würde. Es ist ein gefährlicher Irrglaube, den die DBMS-Entwickler nicht unterstützen.

Die Wurzeln dieses Irrglaubens sind klar: Aggressive Werbung der Entwickler von virtuellen Maschinen und Backup-Tools erwähnt üblicherweise nicht, dass Datenbanken wie auch andere intensiv aktualisierte Dateien eine erweiterte Konfiguration erfordern. Glauben Sie nicht dem Hype – nicht alle Joghurts haben den gleichen Nutzen.

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

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

12. Ersetzen von Backup durch Replikation

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

Alle lieben die Replikation wegen der Möglichkeit, Daten auf einem anderen Server mit minimaler Verzögerung zu synchronisieren, aber auch das Backup hat einige unbestrittene Vorteile. Beispielsweise wird die Replikation bei versehentlichem (oder absichtlichem) Löschen von Daten die Änderungen schnell und ungerührt an das Replikat senden, während das Backup (insbesondere mit Kopien auf schreibgeschützten Medien) gegen solche Operationen immun ist. Es erfordert einen gewissen Aufwand, sowohl Replikation als auch Backup korrekt zu konfigurieren, und dennoch besteht die Möglichkeit von Fehlern trotzdem.

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

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

Zusammenfassung

Es ist nicht so einfach, das Backup für Ihr Lieblings-DBMS zu konfigurieren, daher verwenden Datenbankadministratoren aus Organisationen, in denen man ihre Daten schätzt, üblicherweise professionelle Backup-Tools, die es ihnen ermöglichen, die oben genannten Probleme zu berücksichtigen und die Schwierigkeiten zu vermeiden.

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

Außerdem bietet unser Unternehmen vollständige Backup- und Wartungsunterstützung für Firebird und andere Datenbanken an, dies ist eine gute Wahl für diejenigen, die nicht über alle technischen Details von Backups Bescheid wissen.

Und natürlich pflegen Sie weiterhin Ihre Admin-Paranoia, stehen Sie zum Beispiel auf und überprüfen Sie Ihre Sicherungskopien genau jetzt :)

Kontakte

Bitte zögern Sie nicht, uns Fragen zu stellen: [email protected]

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