Leitfaden zur Datenbanksicherung

– Nun, kein Schutzraum hält einem Meteoriteneinschlag stand. Aber Sie haben, wie jeder andere auch, eine Sicherung, also brauchen Sie sich keine Sorgen zu machen.

Stanislaw Lem, „Die Sterntagebücher des Ijon Tichy“

Die Datensicherung bezeichnet die Speicherung einer Kopie von Daten außerhalb des Hauptspeichers.

Der Hauptzweck der Datensicherung besteht darin, Daten nach einem Verlust wiederherzustellen. In diesem Zusammenhang hört man oft, dass man mit einer Datenbankreplik immer Daten wiederherstellen kann und eine Sicherung nicht notwendig ist. Tatsächlich ermöglicht die Datensicherung die Lösung von mindestens drei Aufgaben, die mit einer Replik nicht gelöst werden können, und man kann eine Replik ohne Sicherung nicht initialisieren.

Erstens ermöglicht eine Sicherung die Wiederherstellung von Daten nach einem logischen Fehler. Zum Beispiel, wenn ein Buchhalter eine Gruppe von Buchungen gelöscht hat oder ein Datenbankadministrator einen Tablespace zerstört hat. Beide Operationen sind nach den Regeln der Datenbank völlig legitim, und der Replikationsprozess wird diese in der Replikatdatenbank reproduzieren.

Zweitens sind moderne Datenbankmanagementsysteme äußerst zuverlässige Softwarelösungen, jedoch kann es gelegentlich zu Beschädigungen der internen Datenbankstrukturen kommen, wodurch der Zugriff auf Daten verloren geht. Besonders ärgerlich ist, dass solche Störungen häufig bei hoher Auslastung oder während der Installation von Updates auftreten. Sowohl hohe Lasten als auch regelmäßige Updates deuten darauf hin, dass die Datenbank keineswegs eine Testumgebung ist und die darin gespeicherten Daten wertvoll sind.

Schließlich ist die dritte Aufgabe, deren Lösung eine Sicherungskopie erfordert, das Klonen der Datenbank, beispielsweise zu Testzwecken.

Die Sicherung von Datenbanken basiert in der einen oder anderen Form auf einem der beiden Prinzipien:

• Datenextraktion mit anschließender Speicherung im beliebigen Format;
• Snapshot des Zustands der Datenbankdateien und Speicherung der Protokolle.

Lassen Sie uns diese Prinzipien und die verwendeten Werkzeuge näher betrachten.

Datenexport

Im Lieferumfang der mit jeder Datenbank-Management-System (DBMS) gelieferten Tools sind unbedingt Werkzeuge zur Datenexport und -import enthalten. Die Daten werden entweder im Textformat oder im binären, spezifischen Format des jeweiligen DBMS gespeichert. Die folgende Tabelle zeigt eine solche Liste von Werkzeugen:

Binärformat
Textformat

Oracle
DataPump Export/DataPump Import
Export/Import
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
unload/load
unload/load

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra,
nodetool snapshot/sstableloader
cqlsh

Der Vorteil des Textformats liegt darin, dass es mit externen Programmen bearbeitet oder sogar erstellt werden kann, während das Binärformat schnelleres Exportieren und Importieren von Daten ermöglicht, da es Ressourcen bei der Formatumwandlung spart.

Trotz der Einfachheit und Offensichtlichkeit der Idee des Datenexports wird diese Methode selten für die Sicherung stark belasteter Produktionsdatenbanken verwendet. Hier sind die Gründe, warum der Export nicht für ein vollständiges Backup geeignet ist:

• Der Exportprozess erzeugt eine erhebliche Belastung für das Quellsystem;
• Der Export nimmt viel Zeit in Anspruch – zum Zeitpunkt des Abschlusses des Exports wird er bereits nicht mehr aktuell sein;
• Es ist praktisch unmöglich, einen konsistenten Dump der gesamten Datenbank bei hoher Last zu erstellen, da das DBMS gezwungen ist, einen Snapshot seines Zustands zum Zeitpunkt des Beginns des Dumps zu speichern. Je mehr Transaktionen seit Beginn des Dumps durchgeführt wurden, desto größer ist das Volumen des Snapshots (veraltete Datenkopien in PostgreSQL, Undo-Speicher in Oracle, tempdb in Microsoft SQL Server usw.);
• Der Dump bewahrt die logische Struktur der Daten, jedoch nicht deren physische Struktur – die Parameter der physischen Speicherung von Tabellen, Indizes usw.

Dennoch hat der Dump auch Vorteile:

• Hohe Selektivität: Es können einzelne Tabellen, spezifische Felder und sogar einzelne Zeilen exportiert werden;
• Die exportierten Daten können in eine Datenbank einer anderen Version geladen werden, und wenn der Dump im Textformat erfolgt, auch in eine andere Datenbank.

Somit wird der Dump hauptsächlich für Aufgaben wie die Sicherung kleiner Tabellen (z. B. Verzeichnisse) oder die Verbreitung von Datensätzen mit der nächsten Anwendungsrelease verwendet.

Die am häufigsten verwendete Methode zur Sicherung von Datenbanken bleibt jedoch das Kopieren der Datenbankdateien.

Kalte Datenbanksicherung

Die naheliegende Idee ist, die Datenbank anzuhalten und alle Dateien zu kopieren. Eine solche Sicherung wird als "kalte" Sicherung bezeichnet. Diese Methode ist äußerst zuverlässig und einfach, hat jedoch zwei offensichtliche Nachteile:

• Aus einer "kalten" Sicherung kann nur der Zustand der Datenbank wiederhergestellt werden, der zum Zeitpunkt des Anhaltens bestand; Transaktionen, die nach dem Neustart der Datenbank durchgeführt wurden, gelangen nicht in die "kalte" Sicherung.
• Nicht jede Datenbank hat ein Zeitfenster, in dem sie gestoppt werden kann.

Wenn Sie jedoch mit der "kalten" Sicherung zufrieden sind, sollten Sie beachten, dass

• die "kalte" Sicherung manchmal auch Protokolle enthalten muss. Die Methoden zur Bestimmung der Protokolle, die in die "kalte" Sicherung aufgenommen werden sollen, sind für jede DBMS individuell. Zum Beispiel müssen bei Oracle die sogenannten Online-Redo-Dateien kopiert werden, d.h. eine feste Anzahl von Protokolldateien in einem speziellen Verzeichnis, selbst wenn die Datenbank korrekt angehalten wurde. In PostgreSQL müssen alle Protokolle ab dem Protokoll, das den letzten Kontrollpunkt enthält, gesichert werden, dessen Informationen in der Steuerdatei gespeichert sind.
• Das Datenbankverzeichnis kann recht große Dateien von temporären Tabellenräumen enthalten, die nicht unbedingt in das Backup aufgenommen werden müssen. Übrigens gilt diese Anmerkung auch für die "heiße" Sicherung.

"Heiße" Dateispeicherung

Die meisten Backups moderner Datenbanken werden durchgeführt, indem die Datenbankdateien kopiert werden, ohne die Datenbank anzuhalten. Dabei gibt es einige Probleme:

• Zum Zeitpunkt des Beginns der Kopie kann der Inhalt der Datenbank vom Inhalt der Dateien abweichen, da ein Teil der Informationen im Cache gespeichert ist und noch nicht auf die Festplatte geschrieben wurde.
• Während des Kopiervorgangs kann sich der Inhalt der Datenbank ändern. Wenn veränderbare Datenstrukturen verwendet werden, ändert sich der Inhalt der Dateien, und bei unveränderbaren Strukturen ändert sich das Set von Dateien: neue Dateien erscheinen, während alte gelöscht werden.
• Da das Schreiben von Daten in die Datenbank und das Lesen der Datenbankdateien nicht synchronisiert sind, kann das Backup-Programm eine inkorrekte Seite lesen, bei der die eine Hälfte von der alten Version der Seite und die andere Hälfte von der neuen stammt.

Um eine konsistente Sicherung zu erhalten, verfügt jedes DBMS über einen Befehl, der anzeigt, dass der Sicherungsprozess gestartet wurde. Die Syntax dieses Befehls kann unterschiedlich aussehen:

• in Oracle ist dies ein separater Befehl ALTER DATABASE/TABLESPACE BEGIN BACKUP;
• in PostgreSQL – die Funktion pg_start_backup();
• in Microsoft SQL Server und DB2 erfolgt die Vorbereitung für die Sicherung implizit während der Ausführung des Befehls BACKUP DATABASE;
• in MySQL Enterprise, Cassandra und MongoDB wird die Vorbereitung implizit von einem externen Dienstprogramm durchgeführt – mysqlbackup, OpsCenter und Ops Manager entsprechend.

Trotz der syntaktischen Unterschiede sieht der Vorbereitungsprozess für die Sicherung überall ähnlich aus.

So sieht die Vorbereitung für die Sicherung in DBMS mit veränderlichen Speicherstrukturen aus, d. h. in allen traditionellen relationalen Datensystemen:

1. Der Zeitpunkt des Beginns der Sicherung wird aufgezeichnet; das Backup muss die Datenbankprotokolle ab diesem Zeitpunkt enthalten.
2. Ein Sicherungspunkt wird erstellt, wodurch alle Änderungen, die bis zu diesem Moment an den Datenseiten vorgenommen wurden, auf die Festplatte zurückgesetzt werden. Dies gewährleistet, dass die Protokolle vor dem Beginn der Sicherung bei der Wiederherstellung nicht benötigt werden.
3. Ein spezieller Protokollierungsmodus wird aktiviert: Wenn sich die Datenseite zum ersten Mal nach dem Laden von der Festplatte ändert, wird anstelle der Aufzeichnung der Änderungen an der Seite die gesamte Seite in das Protokoll geschrieben. Während des Vorbereitungsvorgangs werden alle Seiten auf die Festplatte geschrieben, sodass die erste Änderung des Blocks immer die gesamte Seite im Protokoll festhält. Wenn die Seite während des Sicherungsvorgangs erneut auf die Festplatte geschrieben wird, führt die nächste Änderung ebenfalls zur Speicherung einer vollständigen Kopie der Seite im Protokoll. Dies gewährleistet, dass, falls die Datenseite beim Kopieren des Datei nicht korrekt sein sollte, die Anwendung des Protokolls sie wiederherstellt.
4. Die Änderung der Header von Datendateien wird blockiert, das heißt, der Teil der Datenänderungen, der nicht in den Protokollen reflektiert wird. Dies stellt sicher, dass der Header korrekt kopiert wird und die Protokolle anschließend korrekt auf die Datendatei angewendet werden.

Nachdem alle oben genannten Schritte abgeschlossen sind, können die Datenbankdateien mit Betriebssystemwerkzeugen wie cp, rsync und anderen kopiert werden. Die Aktivierung des Backup-Modus verringert die Leistung der Datenbank: Erstens erhöht sich das Volumen der Protokolle, und zweitens verlängert sich die Wiederherstellungszeit, falls während des Backup-Modus ein Fehler auftritt, da die Dateikopfzeilen nicht aktualisiert werden. Je schneller das Backup abgeschlossen ist, desto besser ist es für die Datenbank. Daher kann der Einsatz von Tools wie Snapshots des Dateisystems oder BCV (Break Copy Volume) im Speichersystem hier von Vorteil sein. Einige Datenbankmanagementsysteme (Oracle, PostgreSQL) bieten dem Administrator die Möglichkeit, die Kopiermethode selbst auszuwählen, während andere (Microsoft SQL Server) eine Schnittstelle zur Integration eigener Backup-Utilities mit Dateisystemmechanismen oder Speichersystemen bereitstellen.

Nach dem Abschluss der Sicherung muss die Datenbank wieder in den normalen Zustand versetzt werden. In Oracle geschieht dies mit dem Befehl ALTER DATABASE/TABLESPACE END BACKUP, in PostgreSQL durch den Aufruf der Funktion pg_stop_backup(), und in anderen Datenbanken über interne Unterprogramme der entsprechenden Befehle oder externen Dienste.

So sieht das zeitliche Diagramm des Sicherungsprozesses aus:

• Die Vorbereitung zur Sicherung (begin backup) benötigt Zeit, manchmal auch erheblich. Selbst wenn Spiegel-Volumes oder Dateisysteme mit Snapshot-Funktionalitäten verwendet werden, wird der Sicherungsprozess nicht sofort abgeschlossen sein.
• Zusammen mit den Datenfiles müssen die Logs ab dem Zeitpunkt des Beginns der Vorbereitungen zur Sicherung bis zum Moment der Rückkehr der Datenbank in den normalen Zustand aufbewahrt werden.
• Diese Sicherung kann wiederhergestellt werden zum Zeitpunkt der Rückkehr der Datenbank in den normalen Zustand. Eine Wiederherstellung auf einen früheren Zeitpunkt ist nicht möglich.

Bei Datenbanken, die unveränderliche Datenstrukturen nutzen (z. B. Memory Snapshots, LSM-Bäume), gestaltet sich die Situation einfacher. Die Vorbereitung zur Sicherung besteht aus folgenden Schritten:

1. Daten aus dem Speicher werden auf die Festplatte geschrieben.
2. Eine Liste der Dateien, die in das Backup aufgenommen werden, wird festgehalten. Solange der Backup-Prozess nicht abgeschlossen ist, ist es der Datenbank untersagt, diese Dateien zu löschen, selbst wenn sie nicht mehr benötigt werden.

Nach dem Signal, dass das Backup abgeschlossen ist, kann die Datenbank mit unveränderlichen Strukturen wieder nicht benötigte Dateien löschen.

Wiederherstellung auf einen Punkt

Ein Backup ermöglicht es, den Zustand der Datenbank zu einem Zeitpunkt wiederherzustellen, als der Befehl zum Verlassen des Backup-Modus abgeschlossen wurde. Ein Ausfall, nach dem eine Wiederherstellung erforderlich ist, kann jedoch jederzeit eintreten. Die Aufgabe, den Zustand der Datenbank zu einem beliebigen Zeitpunkt wiederherzustellen, wird als „Wiederherstellung auf einen Punkt“ (point-in-time recovery) bezeichnet.

Um diese Möglichkeit sicherzustellen, müssen die Datenbankprotokolle ab dem Zeitpunkt des Backup-Endes aufbewahrt werden, und während der Wiederherstellung sollten die Protokolle auf die wiederhergestellte Kopie angewendet werden. Sobald die Datenbank aus dem Backup zum Zeitpunkt des Kopierens wiederhergestellt ist, ist der Zustand der Datenbank (Dateien und zwischengespeicherte Seiten) garantiert korrekt, weshalb ein spezielles Protokollierungsverfahren nicht erforderlich ist. Durch die Anwendung der Protokolle bis zu dem gewünschten Zeitpunkt kann der Zustand der Datenbank zu jedem beliebigen Zeitpunkt erreicht werden.

Wenn die Wiederherstellungsgeschwindigkeit eines Backups nur durch die Festplattendurchsatzgeschwindigkeit begrenzt ist, wird die Geschwindigkeit der Anwendung von Protokollen normalerweise durch die CPU-Leistung limitiert. Wenn in der Hauptdatenbank parallele Änderungen stattfinden, geschieht die Wiederherstellung aller Änderungen sequenziell – in der Reihenfolge, in der sie aus dem Protokoll gelesen werden. Dadurch hängt die Wiederherstellungszeit linear davon ab, wie weit der Wiederherstellungspunkt vom Ende des Backups entfernt ist. Aus diesem Grund ist es notwendig, häufig vollständige Backups zu erstellen – mindestens einmal pro Woche für Datenbanken mit geringer Transaktionslast und bis zu täglichen Backups für stark ausgelastete Datenbanken.

Inkrementelles Backup

Um die Wiederherstellung zu beschleunigen, wäre es ideal, so oft wie möglich Backups durchführen zu können, ohne dabei unnötig Speicherplatz auf den Festplatten zu beanspruchen oder die Datenbank durch Backup-Aufgaben zusätzlich zu belasten.

Die Lösung des Problems ist inkrementelle Datensicherung, das heißt, es werden nur die Datenbanken gesichert, die sich seit der letzten Sicherung verändert haben.
Inkrementelle Datensicherung macht nur bei Datenbanken mit veränderlichen Datenstrukturen Sinn.

Der Inkrement kann entweder von einem vollständigen Backup (kumulatives Backup) oder von jedem vorherigen Backup (differenzielles Backup) ausgehen.

Leider gibt es keine einheitliche Terminologie, und verschiedene Anbieter verwenden unterschiedliche Begriffe:

Differenziell
Kumulativ

Oracle
Differential
Cumulative

PostgresPro
Inkremental
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Inkremental

Bei vorhandenen Inkrementalen sieht der Wiederherstellungsprozess wie folgt aus:

• Die letzte vollständige Sicherung, die vor dem Wiederherstellungspunkt erstellt wurde, wird wiederhergestellt;
• auf die vollständige Sicherung werden die inkrementellen Sicherungen aufgespielt;
• die Protokolle werden von dem Zeitpunkt der Sicherung bis zum Wiederherstellungspunkt angewendet.

Eine kumulative Sicherung beschleunigt den Wiederherstellungsprozess. Um beispielsweise den Zustand der Datenbank zwischen T3 und T4 wiederherzustellen, müssen zwei inkrementelle Sicherungen wiederhergestellt werden, während für die Wiederherstellung auf einen Punkt nach T4 nur eine benötigt wird.
Es ist offensichtlich, dass das Volumen einer kumulativen Sicherung kleiner ist als das Volumen mehrerer differenzieller Sicherungen, da einige Seiten mehrfach geändert wurden und jede inkrementelle Sicherung ihre eigene Version der Seite enthält.

Es gibt drei Möglichkeiten, eine inkrementelle Sicherung zu erstellen:

1. Erstellung einer vollständigen Sicherung und Berechnung der Unterschiede zur vorherigen vollständigen Sicherung;
2. Analyse der Protokolle, Erstellen einer Liste der geänderten Seiten und Sichern der Seiten, die in dieser Liste enthalten sind;
3. Anforderung der geänderten Seiten in der Datenbank.

Die erste Methode spart Speicherplatz, löst jedoch nicht das Problem der Reduzierung der Last auf die Datenbank. Darüber hinaus ist es unsinnig, eine vollständige Sicherung in inkrementelle umzuwandeln, da die Wiederherstellung einer vollständigen Kopie schneller erfolgt als die Wiederherstellung einer vorherigen vollständigen Kopie und der Inkremenet. Das Problem der Speicherplatzeinsparung sollte in einem solchen Ansatz besser auf spezielle Komponenten mit integrierten Deduplizierungsmechanismen übertragen werden. Dies können sowohl spezielle Speicherlösungen (z. B. EMC DataDomain, HPE StorageWorks VLS, die gesamte Produktpalette von NetApp) als auch Softwareprodukte (z. B. ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication) sein.

Die zweite und dritte Methode unterscheiden sich durch den Mechanismus zur Feststellung der Liste der geänderten Seiten. Die Analyse von Protokollen ist ressourcenintensiver, und es ist notwendig, die Struktur der Protokolldateien zu kennen, um sie zu implementieren. Am einfachsten ist es, die Datenbank selbst nach den genau geänderten Seiten zu fragen, doch dafür muss der Kern des DBMS über die Funktionalität zur Verfolgung geänderter Blöcke (Block Change Tracking) verfügen.

Die Funktionalität für inkrementelle Backup-Erstellungen wurde erstmals in der Software Oracle Recovery Manager (RMAN) eingeführt, die mit der Version Oracle 8i herauskam. Oracle implementierte sofort die Überwachung von geänderten Blöcken, wodurch eine Analyse der Protokolle überflüssig wurde.

PostgreSQL verfolgt keine geänderten Blöcke, weshalb das Tool pg_probackup, entwickelt von der russischen Firma Postgres Professional, die geänderten Seiten durch die Analyse der Protokolle bestimmt. Allerdings liefert das Unternehmen auch die Datenbank PostgresPro, die die Erweiterung ptrack enthält, um Änderungen an Seiten zu überwachen. Bei der Verwendung von pg_probackup mit der Datenbank PostgresPro fragt das Tool die geänderten Seiten direkt bei der Datenbank ab – ähnlich wie RMAN.

Microsoft SQL Server verfolgt wie Oracle die geänderten Seiten, jedoch erlaubt der Befehl BACKUP nur vollständige und kumulative Backups.

In DB2 gibt es die Möglichkeit, geänderte Seiten zu überwachen, jedoch ist diese standardmäßig deaktiviert. Nach der Aktivierung ermöglicht DB2 die Erstellung von vollständigen, differenziellen und kumulativen Backups.

Ein wichtiges Unterscheidungsmerkmal der in diesem Abschnitt beschriebenen Mittel (außer pg_probackup) im Vergleich zu dateibasierten Sicherungswerkzeugen besteht darin, dass sie Seitenabbilder von der Datenbank abfragen, anstatt die Daten selbstständig vom Disk zu lesen. Der Nachteil dieses Ansatzes ist die kleine zusätzliche Belastung für die Datenbank. Dieser Nachteil wird jedoch mehr als ausgeglichen durch die Tatsache, dass das gelesene Blatt stets korrekt ist, weshalb es nicht notwendig ist, während der Sicherungszeit einen speziellen Protokollierungsmodus zu aktivieren.

Bitte beachten Sie erneut, dass das Vorhandensein von inkrementellen Sicherungen nicht die Anforderungen an die Protokolle zur Wiederherstellung zu einem beliebigen Zeitpunkt aufhebt. Daher werden in industriellen Datenbanken die Protokolle kontinuierlich auf ein externes Medium geschrieben, während vollständige und/oder inkrementelle Sicherungen planmäßig erstellt werden.

Die beste Umsetzung der Idee der inkrementellen Sicherung ist derzeit das Software-Hardware-System (in der Terminologie von Oracle – engineered system) Zero Data Loss Recovery Appliance – eine spezialisierte Lösung von Oracle für die Sicherung seiner eigenen Datenbank. Das System ist ein Cluster. Server mit großem Speicherplatz, auf dem eine modifizierte Version der Software Recovery Manager installiert ist. Diese kann sowohl mit anderen Software-Hardware-Komplexen von Oracle (Database Appliance, Exadata, SPARC Supercluster) als auch mit Oracle-Datenbanken auf traditioneller Infrastruktur arbeiten. Im Gegensatz zu 'normalem' RMAN implementiert ZDLRA das Konzept des 'ewigen Inkrements' (incremental forever). Das System erstellt einmalig eine vollständige Kopie der Datenbank und erstellt anschließend nur inkrementelle Kopien. Zusätzliche RMAN-Module ermöglichen es, Kopien zu kombinieren und neue vollständige Kopien aus inkrementellen zu erstellen.

Den russischen Entwicklern gebührt das Verdienst, dass auch pg_probackup in der Lage ist, inkrementelle Kopien zu kombinieren.

Im Unterschied zu vielen ähnlichen Fragen hat die Frage 'Welche Backup-Methode ist die beste?' eine klare Antwort – am besten ist das native Tool der verwendeten Datenbank, das die Möglichkeit des inkrementellen Backups bietet.

Für einen DB-Administrator sind die Fragen der Auswahl einer Backup-Strategie und die Integration von Datenbanksicherheitslösungen in die Unternehmensinfrastruktur viel wichtiger. Diese Fragen gehen jedoch über den Rahmen dieses Artikels hinaus.

Quelle: habr.com