Die allermeisten Anwendungen, ob online oder lokal, fußen auf einer Datenbank. Kein Wunder, sind sie doch das ideale Tool, um Informationen innerhalb einer Anwendung zu speichern und zu verwalten. Datenbanken nehmen dem Administrator viel Arbeit im Hinblick auf das Garantieren von Konsistenzen und anderen Funktionen ab. Und weil MySQL, PostgreSQL & Co. bereits ein Weilchen auf dem Buckel haben, gelten sie als erprobt und wenig fehleranfällig. Obendrein sind die beiden genannten Vertreter kostenlos und unter freier Lizenz zu beziehen. De facto ist MySQL so erfolgreich, dass moderne Datenbanken unter der Haube zwar völlig anders funktionieren als das Original, sie dessen Protokoll für die Kompatibilität mit Anwendungen aber trotzdem nachbauen.

Aus Sicht des Administrators ist die zentrale Bedeutung von Datenbanken allerdings nicht nur Grund zur Freude. Denn gerade deshalb ist eine Database in jedem Setup stets ein neuralgischer Punkt. Fliegt dem Administrator der Server um die Ohren, der die Datenbank beheimatet, ist Feuer unterm Dach. Und löscht ein Administrator während eines Notfalls in der Bereitschaftszeit die falsche Tabelle oder gleich die ganze Datenbank, zieht das eine Downtime von etlichen Stunden nach sich.

Mehr als bei allen anderen Teilen einer Infrastruktur gilt für Datenbanken deshalb: Sicherungen sind überlebenswichtig. Und mindestens so entscheidend wie das Backup selbst ist, dass es sich im Notfall schnell und zuverlässig einspielen lässt. Beide Faktoren allerdings, das richtige Sichern und das richtige Wiederherstellen, sind in der Praxis viel komplexer, als es in der Theorie den Anschein hat.

Hinzu kommt, dass es am Markt zwar eine Vielzahl von Werkzeugen gibt, die auch das Backup von Datenbanken im Vorbeigehen miterledigen – so zumindest die Werbeversprechen der Hersteller. Um das richtige Tool für eine Aufgabe auszuwählen, muss der Administrator allerdings genau wissen, welche Funktionalität er benötigt und welche Helfer für sein spezifisches Set-up überhaupt infrage kommen.

Ein großer Teil der Herausforderungen liegt dabei im Funktionsprinzip von Datenbanken selbst begründet. Vorab: Dieser Artikel bezieht sich ausschließlich auf relationale Datenbanken mit dem Fokus auf MySQL oder MariaDB. Geht es um modernere Datenbanken wie Yugabyte, das unter der Haube eigentlich ein Key-Value-Store ist, gelten andere Regeln und Voraussetzungen als in diesem Artikel beschrieben.

Relationale Datenbanken oder kurz RDBMS-Werkzeuge (Relational Database Management System) folgen spezifischen Regeln, um Garantien wie ACID (Atomicity, Consistency, Isolation und Durability) zu bieten. Sie fußen auf dem Prinzip von Datenbanken und sich darin befindlichen Tabellen mit Zeilen und Spalten. Abfragen und Änderungen pflegen relationale Datenbanken nach festen Mustern in den eigenen Datenbestand ein, indem sie die eingehenden Daten zunächst in einer Art Journal speichern (Write-Ahead Log, kurz WAL). Erst von dort aus landen die Daten dann in den Dateien, die die Datenbank ausgibt, wenn ein Benutzer oder eine Anwendung eine entsprechende Anfrage startet.

Das Ablegen im WAL und die Transition der Daten von dort in den fixen Datenbestand folgen dabei festen Regeln. So stellt eine Datenbank beispielsweise sicher, dass konkurrierende Zugriffe auf denselben Teil eines Datensatzes die Datenbank nicht beschädigen und einen inkonsistenten Zustand hervorrufen. Zwar ist dadurch nicht ausgeschlossen, dass ein Client die Änderungen eines anderen Clients gleich wieder überschreibt. Der Administrator darf sich aber darauf verlassen, dass die Datenbank stets in einem vollständig intakten Zustand ist.

Aus dem beschriebenen Funktionsprinzip ergeben sich weitreichende Konsequenzen für den gesamten Themenkomplex "Backup von Datenbanken". Manche Administratoren gehen das Thema dabei hemdsärmelig an und setzen auf simpelste Werkzeuge auf der Kommandozeile, etwa mysqldump. Richtig ist, dass sich der gesamte Inhalt einer Datenbank auf diese Weise sichern lässt. Trotzdem ist der Ansatz eher grobschlächtig. Denn einerseits sichert der vollständige Dump einer Datenbank tatsächlich deren Daten. Zu einer Datenbank gehören neben den Daten aber eben auch die Metadaten in Form der WAL-Dateien. Und die fallen beim Backup per mysqldump hinten über.

Das bedeutet konkret: Zwar lässt sich der Zustand einer Datenbank aus einem MySQL-Dump tatsächlich wiederherstellen. Das funktioniert aber stets nur für den gesamten Datensatz, der in der Dump-Datei hinterlegt ist. Tatsächlich bietet das Tool Optionen, um etwa nur einzelne Datenbanken einer MySQL-Instanz oder einzelne Tabellen zu sichern. Die müssen im weiteren Verlauf dann aber auch komplett wiederhergestellt werden. Und wer diesen Weg beschreitet, bekommt obendrein Probleme, weil der Dump wirklich nur die Daten enthält, aber etwa keine Informationen zur Struktur der Datenbank – falls es sich nicht um einen kompletten Dump der gesamten Datenbank handelt. Eine Point-in-Time-Recovery, also das Wiederherstellen des Datensatzes zu einem bestimmten Zeitpunkt, ist auf diesem Wege nicht möglich.

Obendrein ist der Ansatz mit mehreren Problemen verbunden, die Administratoren im Vorfeld oft gar nicht auf dem Schirm haben. Da ist zunächst die Frage, wie der Administrator sicherstellt, dass der per mysqldump gezogene Inhalt einer Datenbank in sich konsistent ist. Ab Werk hält das Tool die laufende Datenbank während der Ausgabe nämlich nicht an. Das führt im schlimmsten Fall dazu, dass eine Veränderung des Datensatzes gerade dann stattfindet, wenn der Administrator das Backup per mysqldump zieht. Die Datenbank ist dann weiterhin konsistent, das Backup per se aber eben nicht. Die Wiederherstellung eben dieses Backups wäre aus Sicht des Administrators insofern zumindest mit manuellem Mehraufwand verbunden, weil er den defekten Datensatz in der Datenbank im Nachgang des Wiederherstellungsprozesses händisch flicken müsste.

Immerhin lässt sich dieses Problem umgehen, indem der Administrator beim Anlegen des Backups für mysqldump zusätzliche Parameter mitgibt, etwa

Dann legt das Werkzeug einen Punkt bei der Ausgabe fest, bis zu dem es Änderungen exportiert. Falls sich während der Ausgabe die Datenbank dann noch verändert, ignoriert mysqldump die Änderungen. Die Wiederherstellung eines solchen Backups hat dann zwar im ungünstigsten Falle ein paar Commits der jüngsten Vergangenheit nicht. Das dürfte dem Admin in den meisten Fällen aber lieber sein als eine defekte Datenbank oder eine stundenlange Downtime.

Hinzu kommt dabei allerdings noch ein weiterer Faktor, den viele Administratoren unterschätzen. Die gesamte Ausgabe der kompletten Datenbank ist nämlich nur dann eine valide Option, wenn die enthaltenen Daten selbst übersichtlich und sowohl ihre gesamte Ausgabe als auch das Wiedereinspielen eines Dumps später schnell zu erledigen sind. Vielen Admins ist gar nicht klar, dass die eigene Datenbank mittlerweile eine stattliche Größe erreicht hat.

Wer dann in definierten Intervallen – etwa alle sechs Stunden – einen kompletten Datenbank-Dump zieht, erhöht nicht nur die Last auf der Datenbank erheblich, sondern nimmt auch recht lange Zeiten bei der Wiederherstellung in Kauf.

Direkt damit in Verbindung steht der wohl größte Nachteil der händischen Datensicherung mittels mysqldump: Das Fehlen der Möglichkeit, inkrementelle Backups anzulegen. Andere Tools für das Sichern von Datenbanken bieten eine Point-in-Time-Recovery-Funktion. Diese stellt auf Zuruf den Zustand einer Datenbank zu einem spezifischen Zeitpunkt wieder her. Tests etwa von Entwicklern werden dadurch deutlich erleichtert. Denn geht ein Test schief, ist es für den Admin nur eine Sache weniger Befehle, die falsche Änderung rückgängig zu machen.

Hantiert er hingegen unmittelbar mit mysqldump auf der Kommandozeile, müsste er zumindest die gesamte betroffene Tabelle löschen und wiederherstellen – wenn nicht gar die gesamte Datenbank. Und das dauert unter Garantie deutlich länger als das Zurückspielen einzelner Transaktionen.

Die beschriebenen Probleme mit mysql-dump sind auch der Grund dafür, dass ein – leider noch immer – oft anzutreffender Ansatz im Kontext von relationalen Datenbanken weitere Probleme mit sich bringt, und zwar beim Sichern der Dateien der Datenbank im Dateisystem. Im ersten Augenblick mag dies wie die simpelste Lösung wirken. Denn regelmäßig finden sich die zu MySQL gehörenden Dateien in "/var/lib/mysql". Da liegt die Idee nahe, diesen Ordner einfach in das Backup zu verfrachten.

In diesem Szenario hat der Administrator jedoch noch weniger Kontrolle über den exakten Inhalt der Datenbank, den er gerade sichert. Befindet sich die Datenbank zu diesem Zeitpunkt etwa im Wiederherstellungsprozess, könnte der Admin mittels "mysqldump" gar kein Backup anfertigen, weil die Datenbank auf Anfragen nicht reagieren würde. Das Wegsichern der Dateien würde in diesem Szenario weiterhin funktionieren – dem Administrator allerdings auch ein Datenbankbackup in einem weitgehend unspezifizierten Zustand liefern.

Ob und inwiefern sich daraus eine laufende Datenbank später wiederherstellen lässt, ist vorrangig eine Glücksfrage. Entsprechend tun Admins gut daran, diesen Ansatz nicht weiter zu verfolgen.

Stellt sich freilich die Frage, welche Werkzeuge dem Administrator denn anstelle des beschriebenen Weges mit mysqldump zur Verfügung stehen. Eine pauschale Antwort ist an dieser Stelle leider unmöglich, doch stehen verschiedene Möglichkeiten bereit, sich dem Thema zu nähern. Vorteile haben dabei IT-Verantwortliche, die in ihrem Unternehmen bereits auf umfassende Backupsoftware wie Bacula, Bareos oder Veeam setzen. Denn all diesen Wunschlos-Glücklich-Werkzeugen ist MySQL (ebenso übrigens wie PostgreSQL) wohlbekannt, und alle diese Tools bieten für relationale Datenbanken umfassende Backupfunktionen. Unter der Haube sind diese teils stark differierend implementiert, und zum Teil kommt auch das schon ausführlich diskutierte mysqldump dabei wieder zum Einsatz. Hier gilt es aus Sicht des Administrators insofern abzuwägen. Das Beispiel Bareos macht das schnell deutlich.

Denn in Bareos stehen gleich mehrere Methoden zur Verfügung, um MySQL-Datenbanken zu sichern. Die einfachste Option ist das "bpipe"-Plug-in. Das macht genau, was der Name suggeriert. Es startet ein Programm und leitet dessen Ausgabe über die Pipe ("|") auf der Kommandozeile unmittelbar an ein anderes Programm weiter. Die Idee dahinter ist simpel: Der Administrator konfiguriert hier mysqldump mit den oben genannten Parametern als ausgebendes Programm und gibt ein Ziel an, an dem die Daten zu speichern sind. Im Prinzip handelt es sich also nur um mysqldump mit anderen Mitteln, weshalb die oben genannten Einschränkungen für das Szenario gelten.

Variante zwei in Bareos kommt in Form des MySQL-Plug-ins daher, fußt unter der Haube aber ebenfalls auf mysqldump und ist mithin auf das Backup ganzer Datenbanken beschränkt. Hier muss der Admin allerdings weniger Dinge beachten, denn das Plug-in trifft viele Annahmen ab Werk mit sinnvollen Default-Einstellungen.

Die dritte Option, um Daten aus MySQL mit Bareos sinnvoll zu sichern, involviert ein externes Werkzeug und stellt deutlich unter Beweis, dass für Datenbanken die effizientesten Backuptools jene sind, die für diesen einen spezifischen Einsatzzweck entwickelt worden sind. Als Goldstandard für MySQL-Backups gilt in der Community dabei seit einigen Jahren XtraBackup von Percona [1]. Das Tool kommt in Form einer MySQL-Erweiterung daher und klinkt sich unmittelbar in den laufenden Prozess ein, hat also deutlich tieferen Zugriff auf die Daten als etwa mysqldump.

Percona verteilt das Werkzeug unter einer freien Lizenz als Bestandteil eines Bundles mit PerconaDB einerseits und als Erweiterung für generisches MySQL oder MariaDB andererseits. Die Feature-Liste liest sich dabei wie der Traum jedes Datenbankadministrators: InnoDB-Backups ohne Unterbrechung zur Laufzeit sowie MyISAM-Backups für ältere Datenbanken, komplette Kompression für (inkrementelle) Backups, Export einzelner Teile einer Datenbank, Point-in-Time-Recovery und viele weitere Vorteile listet der Hersteller in der Dokumentation. Anders als etwa mysqldump kann XtraBackup auch Backups von Datenbanken anfertigen, die gerade offline sind, etwa weil sie nicht laufen.

Auch wenn der Artikel vom Backup der Dateien in "/var/lib/mysql" zuvor explizit abgeraten hat, geht durch das von Percona bereitgestellte Backup diese Form des Off-linebackups in Ordnung, schon weil das Tool etliche Vorsichtsmaßnahmen trifft, um zuverlässig konsistente Daten zu speichern. Durchaus bemerkenswert ist dabei, dass von Oracle selbst in Form von MySQL Enterprise Backup ebenfalls ein Tool speziell für das Sichern von MySQL-Datenbanken existiert. Dieses kann es in einigen Aspekten allerdings nicht wirklich mit XtraBackup aufnehmen.

Bareos tut in diesem Kontext das einzig richtige und bietet ein Plug-in an, das im Wesentlichen XtraBackup aufruft und dessen Funktionalität integriert. Sich selbst nimmt Bareos dabei zurück und stellt nur den benötigten Speicherplatz für Backups zur Verfügung. Sichert der Admin mit Bareos Daten über das XtraBackup-Plug-in, übernimmt die gesamte Kommunikation mit MySQL das Tool selbst. Und Bareos ist durchaus nicht die einzige Rundumlösung, die XtraBackup integriert. In der einen oder anderen Form findet das Produkt sich unter der Haube der meisten Backuptools.

Im Kontext von Backups sei auf einen weiteren Fallstrick hingewiesen, der schon so manchem Admin zum Verhängnis geworden ist. MySQL und viele andere Datenbanken bieten bekanntlich die Option eines Mehrknoten-Betriebs mit einem primären Knoten und mehreren sekundären Read-Only-Knoten. Das bietet im Alltag viele Vorteile. Weil die meisten Setups stark leselastig sind, hat es sich etwa eingebürgert, Lese- und Schreibanfragen an Datenbanken aufzutrennen und die Leseanfragen an eigens dafür konfigurierte Sekundärknoten weiterzuleiten. Diese lassen sich prinzipiell beliebig skalieren, und in Summe sorgt diese Form des Setups dafür, dass bei der "Hauptdatenbank" wesentlich weniger Last anliegt.

Nicht wenige Administratoren haben den ehernen Grundsatz "Replikation ist kein Backup" allerdings nicht hinreichend verinnerlicht und verlassen sich auf die Replikation zur Datensicherung. Mit teils fatalen Folgen: Insbesondere händische Änderungen wie das versehentliche Löschen von Daten werden schließlich im Rahmen der Replikation unmittelbar an die Kopien der laufenden Hauptinstanz weitergegeben. Sind die Daten dort weg, sind sie also ebenso auf den Replikas weg.

Das bedeutet allerdings nicht, dass sekundäre Systeme in der Praxis des Sicherns von Datenbanken völlig nutzlos sind. Denn ein Replikat der Hauptdatenbank, auf das der Zugriff nur lesend möglich ist, lässt sich grundsätzlich auch als Quelle für Backups verwenden. Das kann besonders dann sehr praktisch sein, wenn die Hauptinstanz der Datenbank mit vielen Anfragen konfrontiert ist und regelmäßige Backups weitere Last hervorrufen würden. Diese Last lässt sich dann ganz wie im normalen Betrieb auf die Replikas umlenken, was die Hauptinstanz entlastet.

In diesem Artikel ist bereits mehrmals angeklungen, dass auch Datenbanken nicht davor gefeit sind, sich technisch weiterzuentwickeln. Im Kontext der Cloud-Ready-Architekturen etwa wird vielerorts der Ruf nach skalierbaren Datenbanken laut, die idealerweise aber gängige Protokolle wie SQL sprechen sollen. Denn für die gibt es am Markt fertige und erprobte Integrationen in etliche Programmier- und Skriptsprachen. Technische Ansätze, um das Problem zu lösen, existieren mittlerweile zuhauf. Yugabyte kam bereits zur Sprache, Vitess erweitert MySQL ebenfalls um Cluster-Fähigkeiten, setzt dabei aber auf das klassische MySQL im Hintergrund, statt dieses durch einen Key-Value-Speicher zu ersetzen.

Einen wiederum völlig anderen Ansatz präsentieren die Entwickler von Dolt [1]. Er lehnt sich vom Konzept her eng an Git an und bietet eine MySQL-Schnittstelle, während es die eigentlichen Daten im Hintergrund mit Git-Syntax und Git-Technik verwaltet. Unter der Haube steckt hier also keine klassische Datenbank, sondern ein Git-ähnliches Konstrukt. Ein eigener Daemon implementiert die SQL-Schnittstelle, die ab Werk mit MySQL kompatibel ist (Bild 3). Der Clou: Änderungen an Daten in Dolt behandelt die Software analog zu "git commit". Jede Änderung an der Datenbank legt im Hintergrund also eine neue Revision des gesamten Datensatzes an, sodass das Backup hier gewissermaßen schon ab Werk integriert ist.

Aus Sicht des Admins macht das das Anlegen tatsächlicher Backups einfach. Denn es genügt, den gesamten Ordner einer laufenden Dolt-Instanz zu sichern. Dieser lässt sich anschließend auf jedem anderen beliebigen System wieder in Betrieb nehmen, wenn dort ebenfalls Dolt installiert ist. Und das beschriebene Szenario ist nur für katastrophale Fehler nötig, in denen der gesamte Host mit der laufenden Dolt-Instanz abhandenkommt. Geht es nur darum, versehentlich gelöschte oder modifizierte Daten wiederherzustellen, genügt auf der Dolt-Ebene ein einfaches "dolt revert" (der Dolt-CLI-Client ist weitgehend kompatibel zu "git" auf der Kommandozeile) mit der Angabe der gewünschten Revision – und fertig ist der Lack.

Das funktioniert ohne Probleme sogar im laufenden Betrieb. Leider ist Dolt augenblicklich noch nicht so flott wie ein getuntes High-Performance-MySQL. An der Geschwindigkeit ihres Produkts arbeiten die Entwickler allerdings auf Hochtouren. Gut möglich, dass sich das Bedienkonzept von Dolt ganz oder in Teilen auch bei anderen Lösungen durchsetzt, sodass Datenbankbackups absehbar ein weniger komplexes Thema werden.

Beim Sichern von Datenbanken gibt es manches zu beachten und fast immer ist die Nutzung spezialisierter Software eine gute Idee. Händische Konstrukte mit mysqldump oder den Pendants für andere DBs mögen im kleinen Maßstab ausreichen. Für große Datenbanken im produktiven Umfeld sind sie es meist nicht. Beachten Sie die praktischen Tipps aus diesem Artikel, sind Sie für die meisten Datenbankprobleme aber gut gewappnet.