Leitfaden zur Sicherung von Datenbanken

– Oh, kein Schutzraum hält einem Meteoriten-Einschlag stand. Aber wie jeder haben Sie auch eine Reserve, sodass Sie sich keine Sorgen machen müssen.

Stanislaw Lem, „Die Star Diaries von Ijon Tichy“

Von einer Datensicherung spricht man, wenn eine Kopie von Daten an einem anderen Ort als dem Hauptspeicherort gespeichert wird.

Das Hauptziel der Datensicherung ist die Wiederherstellung von Daten nach einem Verlust. In diesem Zusammenhang hört man oft, dass bei Vorhandensein eines Replikats der Datenbank die Daten immer wiederhergestellt werden können, und Datensicherung somit unnötig sei. Tatsächlich ermöglicht die Datensicherung jedoch die Lösung von mindestens drei Aufgaben, die mit einem Replikat nicht gelöst werden können, und ein Replikat kann ohne eine Datensicherung nicht initialisiert werden.

Erstens ermöglicht eine Sicherung die Wiederherstellung von Daten nach einem logischen Fehler. Zum Beispiel hat der Buchhalter eine Gruppe von Buchungen gelöscht oder der DB-Administrator hat den Tablespace verworfen. Beide Vorgänge sind aus Sicht der Datenbank absolut legitim und der Replikationsprozess wird diese in der Replikatsdatenbank wiederherstellen.

Zweitens sind moderne DBMSs sehr zuverlässige Softwarepakete, jedoch kommt es gelegentlich zu Beschädigungen der internen Strukturen der Datenbank, nach denen der Zugang zu den Daten verloren geht. Besonders ärgerlich ist, dass solche Störungen gewöhnlich unter hoher Last oder bei der Installation eines Updates auftreten. Sowohl hohe Last als auch regelmäßige Updates deuten darauf hin, dass die Datenbank keineswegs eine Testdatenbank ist und die darin gespeicherten Daten wertvoll sind.

Schließlich ist die dritte Aufgabe, deren Lösung eine Datensicherung erfordert, die Klonierung einer Datenbank, beispielsweise zu Testzwecken.

Die Datensicherung von Datenbanken basiert auf einem der zwei Prinzipien:

• Datenextraktion mit anschließender Speicherung in einem beliebigen Format;
• Snapshot des Zustands der DB-Dateien und Speicherung von Logs.

Lassen Sie uns diese Prinzipien und die Werkzeuge, die sie umsetzen, näher betrachten.

Datenexport

In der Sammlung von Tools, die jeder DBMS beigefügt sind, gibt es unbedingt Werkzeuge für den Datenexport und -import. Die Daten werden entweder im Textformat oder in einem binären Format, das speziell für das jeweilige DBMS geeignet ist, gespeichert. In der folgenden Tabelle finden Sie eine Liste solcher Werkzeuge:

Binäres Format
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
entladen/laden
entladen/laden

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Das Textformat hat den Vorteil, dass es mit externen Programmen bearbeitet oder sogar erstellt werden kann, während das Binärformat schneller Daten auslagern und laden kann, da es bei der Formatumwandlung Ressourcen einspart.

Trotz der Einfachheit und Selbstverständlichkeit der Idee des Datenexports wird dieses Verfahren zur Sicherung stark belasteter Produktionsdatenbanken nur selten angewandt. Hier sind die Gründe, warum ein Export nicht für eine vollständige Datensicherung geeignet ist:

• der Auslagerungsprozess erzeugt eine erhebliche Belastung für das Quellsystem;
• der Export dauert lange – zum Zeitpunkt des Abschlusses ist er nicht mehr aktuell;
• eine konsistente Auslagerung der gesamten Datenbank bei hoher Last ist nahezu unmöglich, da das DBMS gezwungen ist, einen Snapshot seines Zustands zum Zeitpunkt des Beginns des Exports zu behalten. Je mehr Transaktionen seit Beginn des Exports durchgeführt wurden, desto größer ist das Volumen des Snapshots (nicht aktuelle Datenkopien in PostgreSQL, Undo-Räume in Oracle, tempdb in Microsoft SQL Server usw.);
• der Export bewahrt die logische Struktur der Daten, jedoch nicht die physische Struktur – Parameter der physischen Speicherung von Tabellen, Indizes usw.

Dennoch hat der Export auch Vorteile:

• hohe Selektivität: Es können einzelne Tabellen, einzelne Felder und sogar einzelne Zeilen exportiert werden;
• exportierte Daten können in eine Datenbank anderer Versionen geladen werden, und wenn der Export im Textformat durchgeführt wurde, sogar in eine andere Datenbank.

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

Die am häufigsten verwendete Methode zur Datensicherung von Datenbanken ist das Kopieren der Datenbankdateien.

„Kaltes“ Sichern von DB-Dateien

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

• Aus einer "kalten" Sicherungskopie kann nur der Zustand der Datenbank wiederhergestellt werden, der zum Zeitpunkt des Stopps existierte; Transaktionen, die nach dem Neustart der Datenbank durchgeführt wurden, gelangen nicht in die "kalte" Sicherungskopie;
• Nicht jede Datenbank verfügt über ein technologisches Fenster, in dem die Datenbank gestoppt werden kann.

Wenn Sie jedoch mit der "kalten" Datensicherung zufrieden sind, sollten Sie daran denken, dass

• "kalte" Kopien manchmal auch Protokolle enthalten müssen. Die Methoden zur Bestimmung der Protokolle, die in die "kalte" Kopie aufgenommen werden sollten, sind für jedes DBMS unterschiedlich. Zum Beispiel muss in Oracle die sogenannte online redo kopiert werden, also eine feste Anzahl von Protokolldateien in einem speziellen Verzeichnis, und das sogar dann, wenn die Datenbank ordnungsgemäß gestoppt wurde. In PostgreSQL müssen alle Protokolle ab dem Protokoll, das den letzten Kontrollpunkt enthält, der in der Steuerdatei aufgezeichnet ist, aufbewahrt werden.
• Das Verzeichnis der Datenbank kann ziemlich große Dateien temporärer Tabellenräume enthalten, die nicht unbedingt in die Sicherungskopie aufgenommen werden müssen. Übrigens gilt dieser Hinweis auch für "heiße" Sicherungen.

"Heiße" Dateisicherung

Die meisten Sicherungen moderner Datenbanken werden durchgeführt, indem die Datenbankdateien ohne Stopp der Datenbank kopiert werden. Hier gibt es einige Probleme:

• Zum Zeitpunkt des Beginns der Kopierung kann der Inhalt der Datenbank nicht mit dem Inhalt der Dateien übereinstimmen, da ein Teil der Informationen im Cache ist und noch nicht auf die Festplatte geschrieben wurde.
• Während der Kopierung kann sich der Inhalt der Datenbank ändern. Wenn veränderbare Datenstrukturen verwendet werden, ändert sich der Inhalt der Dateien; bei Verwendung unveränderlicher Strukturen ändert sich die Menge der Dateien: neue Dateien erscheinen, während alte gelöscht werden.
• Da das Schreiben von Daten in die Datenbank und das Lesen der DB-Dateien nicht synchronisiert sind, kann das Sicherungsprogramm eine fehlerhafte 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, gibt es in jedem DBMS einen Befehl, der mitteilt, dass der Sicherungsvorgang begonnen hat. Syntaxmäßig kann dieser Befehl unterschiedlich aussehen:

• in Oracle ist es 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 das Backup implizit während der Ausführung des Befehls BACKUP DATABASE;
• In MySQL Enterprise, Cassandra und MongoDB wird die Vorbereitung implizit von einem externen Tool durchgeführt – mysqlbackup, OpsCenter und Ops Manager bzw.

Trotz syntaktischer Unterschiede sieht der Prozess der Vorbereitung für das Backup gleich aus.

So sieht die Vorbereitung für das Backup in Datenbanksystemen mit veränderbaren Speicherstrukturen aus, d.h. in allen traditionellen relationalen Systemen mit Festplattenspeicher:

1. Der Moment des Beginns des Backups wird festgehalten; das Backup muss die Datenbankprotokolle ab diesem Zeitpunkt enthalten.
2. Ein Checkpoint wird durchgeführt, das heißt, alle Änderungen, die bis zu diesem festgehaltenen Moment auf den Datenblättern erfolgt sind, werden auf die Festplatte übertragen. Dadurch wird sichergestellt, dass die Protokolle vor Beginn des Backups beim Wiederherstellen nicht benötigt werden.
3. Ein spezieller Journalisierungsmodus wird aktiviert: Wenn eine Datenblattseite nach dem ersten Laden von der Festplatte geändert wird, wird anstelle der Aufzeichnung der Änderungen an der Seite die gesamte Seite ins Journal geschrieben. Bei der Durchführung des Vorbereitungsprozesses werden alle Seiten auf die Festplatte verdrängt, sodass bei der ersten Änderung der Block immer vollständig ins Journal geschrieben wird. Wenn während des Backups die Seite erneut auf die Festplatte verdrängt wird, führt die nächste Änderung ebenfalls zu einer vollständigen Kopie der Seite im Journal. Dies garantiert, dass, falls die Datei mit den Daten während des Kopiervorgangs fehlerhaft wird, das Anwenden des Journals sie wieder korrekt macht.
4. Die Änderung der Dateikopfzeilen der Daten wird gesperrt, d.h. der Teil, dessen Änderungen nicht in den Journalen refl ektiert werden. Dies garantiert, dass der Kopf korrekt kopiert wird und anschließend die Protokolle korrekt auf die Datendatei angewendet werden.

Nachdem alle oben genannten Verfahren abgeschlossen sind, können die Datenfiles mit den Mitteln des Betriebssystems – cp, rsync und anderen – kopiert werden. Die Aktivierung des Backup-Modus reduziert die Leistung der Datenbank: Erstens erhöht sich das Volumen der Logs, und zweitens, wenn im Backup-Modus ein Fehler auftritt, wird die Wiederherstellung länger dauern, da die Header der Datenfiles nicht aktualisiert werden. Je schneller das Backup abgeschlossen ist, desto besser für die Datenbank, weshalb hier der Einsatz von Mitteln wie einem Snapshot des Dateisystems oder der BCV der Spiegelung im Speichersystem sinnvoll ist. Einige DBMS (Oracle, PostgreSQL) lassen dem Administrator die Wahl des Kopierverfahrens, andere (Microsoft SQL Server) bieten eine Schnittstelle zur Integration eigener Backup-Tools mit den Mechanismen der Dateisysteme oder des Storage-Systems an.

Nach Abschluss des Backups muss die Datenbank wieder in den normalen Zustand versetzt werden. In Oracle geschieht dies mit dem Befehl ALTER DATABASE/TABLESPACE END BACKUP, in PostgreSQL wird die Funktion pg_stop_backup() aufgerufen, und in anderen Datenbanken erfolgen dies durch interne Subroutinen der entsprechenden Befehle oder externen Dienste.

So sieht das zeitliche Diagramm des Backup-Prozesses aus:

• Die Vorbereitung des Backups (begin backup) erfordert Zeit, manchmal erheblich. Selbst wenn spiegelnde Volumes oder Dateisysteme mit Snapshot-Funktionalität verwendet werden, wird der Backup-Prozess nicht sofort abgeschlossen sein.
• Zusammen mit den Datenfiles müssen die Logs ab dem Beginn der Backup-Vorbereitung bis zum Zeitpunkt der Rückkehr der Datenbank in den normalen Zustand gesichert werden.
• Die Wiederherstellung aus diesem Backup ist möglich 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 (Speichersnapshots, LSM-Bäume) verwenden, ist die Situation einfacher. Die Vorbereitung zum Backup umfasst die folgenden Schritte:

1. Die Daten aus dem Speicher werden auf die Festplatte geschrieben.
2. Es wird eine Liste der Dateien erstellt, die in das Backup eingehen. Bis der Backup-Prozess abgeschlossen ist, ist es der Datenbank verboten, diese Dateien zu löschen, selbst wenn sie nicht mehr benötigt werden.

Nach dem Signal zum Ende der Sicherung kann die Datenbank mit unveränderlichen Strukturen erneut unnötige Dateien löschen.

Wiederherstellung zum Punkt

Die Sicherung ermöglicht es, den Zustand der Datenbank zu dem Zeitpunkt wiederherzustellen, an dem der Befehl zum Verlassen des Sicherungsmodus abgeschlossen wurde. Ein Unfall, nach dem eine Wiederherstellung erforderlich ist, kann jedoch jederzeit auftreten. Die Aufgabe, den Zustand der Datenbank zu einem beliebigen Zeitpunkt wiederherzustellen, wird als "Wiederherstellung zum Punkt" (point-in-time recovery) bezeichnet.

Um diese Möglichkeit zu gewährleisten, sollten die Datenbankprotokolle ab dem Zeitpunkt des Endes der Sicherung gespeichert werden, und während des Wiederherstellungsprozesses sollten die Protokolle auf die wiederhergestellte Kopie angewendet werden. Nachdem die Datenbank aus der Sicherung zum Zeitpunkt des Endes der Sicherung wiederhergestellt wurde, ist der Zustand der Datenbank (Dateien und zwischengespeicherte Seiten) garantiert korrekt, daher wird kein spezieller Protokollierungsmodus benötigt. Durch die Anwendung der Protokolle bis zu dem gewünschten Zeitpunkt kann der Zustand der Datenbank zu jedem Zeitpunkt wiederhergestellt werden.

Wenn die Geschwindigkeit der Wiederherstellung der Sicherung nur durch die Bandbreite der Festplatte begrenzt ist, ist die Geschwindigkeit der Anwendung der Protokolle normalerweise durch die Leistung des Prozessors begrenzt. Wenn in der Hauptdatenbank parallele Änderungen stattfinden, werden bei der Wiederherstellung alle Änderungen nacheinander – in der Reihenfolge der Protokolldaten – durchgeführt. Daher hängt die Wiederherstellungszeit linear davon ab, wie weit der Wiederherstellungspunkt vom Ende der Sicherung entfernt ist. Aus diesem Grund müssen vollständige Sicherungen ziemlich häufig durchgeführt werden – mindestens einmal pro Woche für Datenbanken mit geringem Transaktionsaufkommen und bis zu täglichen Sicherungen für stark belastete Datenbanken.

Inkrementelle Sicherung

Um die Wiederherstellung zu einem bestimmten Punkt zu beschleunigen, wäre es wünschenswert, die Sicherung so häufig wie möglich durchführen zu können, ohne dabei zusätzlichen Speicherplatz auf den Festplatten zu beanspruchen oder die Datenbank mit Sicherungsaufgaben zu belasten.

Die Lösung des Problems ist die inkrementelle Sicherung, d. h. das Kopieren nur der Datenblätter, die sich seit der letzten Sicherung geändert haben.
Inkrementelles Backup ist nur für Datenbanksysteme sinnvoll, die veränderbare Datenstrukturen verwenden.

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

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

Differenziell
Kumulativ

Oracle
Differential
Kumulative

PostgresPro
Inkremental
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Inkremental

Wenn Inkrementale Backups vorhanden sind, sieht der Wiederherstellungsprozess zu einem bestimmten Zeitpunkt folgendermaßen aus:

• Die letzte vollständige Sicherung, die vor dem Wiederherstellungspunkt erstellt wurde, wird wiederhergestellt;
• Über dem vollständigen Backup werden die inkrementalen Backups wiederhergestellt;
• Die Protokolle von dem Zeitpunkt des Beginns des Backups bis zum Wiederherstellungspunkt werden angewendet.

Das Vorhandensein eines kumulativen Backups beschleunigt den Wiederherstellungsprozess. Zum Beispiel müssen für die Wiederherstellung des Datenbankzustands zu einem Zeitpunkt zwischen T3 und T4 zwei inkrementale Backups wiederhergestellt werden, während für die Wiederherstellung nach T4 nur eines erforderlich ist.
Offensichtlich ist das Volumen eines kumulativen Backups geringer als das Volumen mehrerer differenzieller Backups, da sich einige Seiten mehrmals geändert haben und jedes inkrementale Backup seine eigene Version der Seite enthält.

Es gibt drei Möglichkeiten, ein inkrementales Backup zu erstellen:

1. eine vollständige Kopie zu erstellen und die Differenz zur vorherigen vollständigen Kopie zu berechnen;
2. Protokolle zu analysieren, eine Liste der geänderten Seiten zu erstellen und die in der Liste enthaltenen Seiten zu sichern;
3. geänderte Seiten in der Datenbank abzufragen.

Der erste Ansatz spart Speicherplatz, löst jedoch nicht das Problem der Reduzierung der Last auf die Datenbank. Darüber hinaus ist es sinnlos, eine vollständige Sicherung in eine inkrementale zu verwandeln, wenn wir bereits eine vollständige Sicherung haben, da die Wiederherstellung einer vollständigen Sicherung schneller ist als die Wiederherstellung einer früheren vollständigen Sicherung und eines Inkrements. Um das Ziel der Reduzierung des Speicherplatzes mit diesem Ansatz zu erreichen, sollten spezielle Komponenten mit integrierten Deduplizierungsmechanismen eingesetzt werden. Dies können sowohl spezielle Speicherlösungen (EMC DataDomain, HPE StorageWorks VLS, die gesamte NetApp-Reihe) als auch Softwareprodukte (ZFS, Veritas NetBackup PureFile, Windows Server Daten-Deduplizierung) sein.

Der zweite und dritte Ansatz unterscheiden sich in der Methode zur Bestimmung der Liste der geänderten Seiten. Die Analyse von Protokollen ist ressourcenintensiver; zusätzlich muss die Struktur der Protokolldateien bekannt sein, um sie zu interpretieren. Es ist am einfachsten, direkt bei der Datenbank nachzufragen, welche Seiten sich geändert haben, jedoch muss dazu das DBMS über die Funktionalität zur Verfolgung geänderter Blöcke (Blockänderungsverfolgung) verfügen.

Die Funktionalität der inkrementellen Datensicherung wurde erstmals in der Software Oracle Recovery Manager (RMAN) implementiert, die mit Oracle 8i eingeführt wurde. Oracle hat sofort die Verfolgung geänderter Blöcke realisiert, sodass keine Notwendigkeit besteht, Protokolle zu analysieren.

PostgreSQL verfolgt keine geänderten Blöcke, daher bestimmt das Tool pg_probackup, entwickelt von der russischen Firma Postgres Professional, geänderte Seiten durch Analyse des Protokolls. Das Unternehmen bietet auch das DBMS PostgresPro an, das die Erweiterung ptrack enthält, die die Änderung von Seiten verfolgt. Bei Verwendung von pg_probackup mit dem DBMS PostgresPro fragt das Tool die geänderten Seiten direkt bei der Datenbank an – genauso wie RMAN.

Microsoft SQL Server verfolgt ebenfalls geänderte Seiten, genau wie Oracle, aber der Befehl BACKUP erlaubt nur vollständige und kumulative Sicherungen.

In DB2 besteht die Möglichkeit, geänderte Seiten zu verfolgen, aber standardmäßig ist diese Funktion deaktiviert. Nach der Aktivierung ermöglicht DB2 das Erstellen von vollständigen, differenziellen und kumulativen Sicherungen.

Ein wichtiger Unterschied zwischen den in diesem Abschnitt beschriebenen Werkzeugen (außer pg_probackup) und dateibasierten Sicherungswerkzeugen besteht darin, dass sie die Seitenabbilder von der Datenbank anfordern, anstatt die Daten selbständig von der Festplatte zu lesen. Der Nachteil dieses Ansatzes ist eine geringe zusätzliche Belastung für die Datenbank. Dieser Nachteil wird jedoch mehr als ausgeglichen durch die Tatsache, dass die gelesene Seite immer korrekt ist, was es überflüssig macht, während der Sicherung einen speziellen Protokollierungsmodus zu aktivieren.

Bitte beachten Sie erneut, dass das Vorhandensein inkrementeller Sicherungen keine Anforderungen an das Vorhandensein von Protokollen für die Wiederherstellung zu einem beliebigen Zeitpunkt aufhebt. Daher werden in professionellen Datenbanken die Protokolle kontinuierlich auf ein externes Medium überschrieben, während vollständige und/oder inkrementelle Sicherungen nach einem Zeitplan erstellt werden.

Die beste Umsetzung der Idee des inkrementellen Backup heute ist das software-hardware Komplettsystem (in der Terminologie von Oracle – engineered system) Zero Data Loss Recovery Appliance – eine spezialisierte Lösung von Oracle für das Backup seiner eigenen Datenbank. Das System besteht aus einem Cluster Server mit einer großen Anzahl von Festplatten, auf denen eine modifizierte Version der Software Recovery Manager installiert ist, und kann sowohl mit anderen Software-Hardware-Systemen von Oracle (Database Appliance, Exadata, SPARC Supercluster) als auch mit Oracle-Datenbanken auf traditioneller Infrastruktur arbeiten. Im Gegensatz zum „gewöhnlichen“ RMAN implementiert ZDLRA das Konzept des „ewigen Inkrements“ (incremental forever). Das System erstellt einmalig eine vollständige Kopie der Datenbank und erstellt dann nur inkrementelle Kopien. Zusätzliche RMAN-Module ermöglichen es, Kopien zu kombinieren, um neue vollständige Kopien aus inkrementellen Kopien zu erstellen.

Zur Ehre der russischen Entwickler muss festgestellt werden, dass auch pg_probackup in der Lage ist, inkrementelle Kopien zu kombinieren.

Im Gegensatz zu vielen ähnlichen Fragen hat die Frage „Welche Backup-Methode ist die beste?“ eine eindeutige Antwort – am besten ist das native Tool der verwendeten DBMS, das die Möglichkeit für inkrementelles Backup bietet.

Für einen DB-Administrator sind Fragen zur Auswahl einer Backup-Strategie und zur Integration von Datenbanksicherungslösungen in die Unternehmensinfrastruktur weit wichtiger. Aber diese Fragen gehen über den Rahmen dieses Artikels hinaus.

Quelle: habr.com