Database Backup Strategie: SQL Dumps und Point-in-Time Recovery (PITR)

Die Sicherung von Datenbanken ist ein zentraler Bestandteil jeder IT-Strategie. Unabhängig davon, ob Datenbanken in einer lokalen Infrastruktur, einer virtualisierten Umgebung oder in der Cloud betrieben werden, besteht jederzeit das Risiko von Hardwareausfällen, Softwarefehlern, Fehlkonfigurationen oder menschlichen Bedienfehlern. Ohne eine durchdachte Backup-Strategie kann bereits ein einzelner Vorfall zu erheblichen Datenverlusten oder langen Ausfallzeiten führen.

Relationale Datenbanksysteme wie MySQL oder MariaDB bieten unterschiedliche Möglichkeiten zur Datensicherung. Dabei unterscheiden sich die Verfahren nicht nur hinsichtlich ihrer technischen Umsetzung, sondern auch hinsichtlich ihres Einsatzzwecks. Während einige Backuparten den vollständigen Zustand eines Datenbankservers inklusive aller Änderungen sichern, konzentrieren sich andere auf einzelne Datenbanken oder sogar einzelne Tabellen.

Grundsätzlich lassen sich Datenbank-Backups in zwei Kategorien einteilen: Infrastruktur-Backups und Client-Backups. Beide verfolgen unterschiedliche Ziele und ergänzen sich in professionellen Backup-Konzepten.

Infrastruktur-Backups – Schutz des gesamten Datenbankservers

Ein Infrastruktur-Backup verfolgt das Ziel, den vollständigen Zustand eines Datenbankservers zu sichern. Im Gegensatz zu einem logischen Export einzelner Datenbanken betrachtet diese Sicherungsart den Datenbankserver als Gesamtsystem. Neben den eigentlichen Daten werden häufig auch Konfigurationen, Benutzerkonten, Berechtigungen sowie weitere serverbezogene Informationen berücksichtigt.

Eine zentrale Rolle spielt hierbei das Point-in-Time Recovery (PITR). Dieses Verfahren kombiniert regelmäßige vollständige Sicherungen mit einer kontinuierlichen Aufzeichnung aller Änderungen, die auf dem Datenbankserver stattfinden. Grundlage hierfür sind die sogenannten Binary Logs (Binlogs).

Die Binary Logs protokollieren sämtliche schreibenden Operationen auf Serverebene. Jede Änderung an einer Datenbank – beispielsweise das Einfügen neuer Datensätze, das Aktualisieren vorhandener Informationen oder strukturelle Änderungen wie das Erstellen oder Löschen von Tabellen – wird chronologisch in den Binlogs gespeichert. Dadurch entsteht eine lückenlose Historie aller Transaktionen, die nach einem vollständigen Backup durchgeführt wurden.

Der entscheidende Unterschied zu einem SQL-Dump besteht darin, dass die Binary Logs nicht auf Ebene einzelner Datenbanken oder Tabellen arbeiten, sondern den gesamten Datenbankserver überwachen. Alle Datenbanken, die auf dem Server betrieben werden, werden gleichermaßen berücksichtigt. Aus diesem Grund zählt das Binlog-basierte Backup zu den Infrastruktur-Backups.

Die Wiederherstellung erfolgt in mehreren Schritten. Zunächst wird ein vollständiges Backup des Servers eingespielt. Anschließend werden die Binary Logs in zeitlicher Reihenfolge angewendet. Dadurch lässt sich der Datenbestand bis zu einem beliebigen Zeitpunkt rekonstruieren. Dieses Verfahren wird als Point-in-Time Recovery bezeichnet.

Ein typisches Szenario ist das versehentliche Löschen einer Tabelle oder das Ausführen eines fehlerhaften UPDATE-Befehls. Während ein klassisches Backup lediglich den Zustand der letzten Sicherung wiederherstellen könnte, ermöglicht PITR eine Wiederherstellung unmittelbar vor dem Zeitpunkt des Fehlers. Der Datenverlust reduziert sich dadurch häufig auf wenige Sekunden oder sogar vollständig.

Aus diesem Grund gilt Point-in-Time Recovery heute als Standardverfahren für produktive Datenbanksysteme mit hohen Anforderungen an Verfügbarkeit und Datensicherheit.

Client-Backups – Logische Sicherung einzelner Datenbanken und Tabellen

Im Gegensatz zum Infrastruktur-Backup arbeitet ein Client-Backup auf logischer Ebene. Hierbei erfolgt die Sicherung über einen Datenbank-Client wie beispielsweise mysqldump.

Anstatt die physischen Datenbankdateien oder Transaktionsprotokolle zu sichern, liest das Werkzeug sämtliche Daten sowie die Datenbankstruktur aus und erzeugt daraus SQL-Anweisungen. Diese SQL-Datei enthält alle notwendigen Befehle, um die Datenbank zu einem späteren Zeitpunkt wieder vollständig aufzubauen.

Ein SQL-Dump kann auf unterschiedlichen Ebenen erstellt werden. Häufig wird eine komplette Datenbank exportiert. Ebenso ist es möglich, lediglich einzelne Tabellen zu sichern oder mehrere ausgewählte Datenbanken gemeinsam zu exportieren. Diese Flexibilität unterscheidet Client-Backups grundlegend von Infrastruktur-Backups.

Da der Export logisch erfolgt, ist das erzeugte Backup unabhängig vom zugrunde liegenden Dateisystem oder der Hardwareplattform. Eine SQL-Dump-Datei kann problemlos auf einen anderen Server übertragen und dort wieder importiert werden. Dadurch eignen sich SQL-Dumps besonders für Migrationen zwischen verschiedenen Servern oder für den Austausch einzelner Datenbanken.

Ein weiterer Vorteil besteht darin, dass einzelne Tabellen gezielt wiederhergestellt werden können. Wurde beispielsweise versehentlich eine Tabelle gelöscht, kann diese aus einem SQL-Dump importiert werden, ohne den gesamten Datenbankserver zurücksetzen zu müssen.

Allerdings besitzt dieses Verfahren auch Einschränkungen. Ein SQL-Dump bildet stets nur den Zustand der Datenbank zum Zeitpunkt des Exports ab. Änderungen, die nach der Erstellung des Dumps erfolgen, sind darin nicht enthalten. Eine Wiederherstellung auf einen beliebigen Zeitpunkt zwischen zwei Sicherungen ist daher nicht möglich.

Gerade bei Datenbanken mit hoher Änderungsrate kann dies zu einem erheblichen Datenverlust führen, sofern ausschließlich SQL-Dumps verwendet werden.

Unterschiede zwischen Infrastruktur-Backup und Client-Backup

Obwohl beide Verfahren der Datensicherung dienen, unterscheiden sie sich grundlegend hinsichtlich ihres Anwendungsbereichs.

Ein Infrastruktur-Backup arbeitet auf Serverebene. Die Binary Logs erfassen sämtliche Änderungen des gesamten Datenbankservers und ermöglichen eine kontinuierliche Absicherung aller darauf befindlichen Datenbanken. Ziel ist die vollständige Wiederherstellung des Servers einschließlich aller Daten bis zu einem exakt definierten Zeitpunkt.

Ein Client-Backup hingegen arbeitet auf Datenbank- oder Tabellenebene. Der Administrator entscheidet gezielt, welche Datenbanken oder Tabellen exportiert werden sollen. Das Backup enthält ausschließlich die ausgewählten Objekte und ist daher besonders flexibel für Migrationen, Archivierungen oder die Wiederherstellung einzelner Datenbestände.

Während Infrastruktur-Backups den Schwerpunkt auf maximale Datensicherheit und minimale Datenverluste legen, stehen bei Client-Backups Portabilität, Flexibilität und eine einfache Handhabung im Vordergrund.

Wann sollte welches Backupverfahren eingesetzt werden?

Welches Verfahren geeignet ist, hängt maßgeblich vom jeweiligen Einsatzszenario ab.

Für produktive Unternehmensanwendungen mit kontinuierlichem Datenverkehr sollte Point-in-Time Recovery den Kern der Backup-Strategie bilden. Datenbanken von ERP-Systemen, Onlineshops, CRM-Lösungen oder Finanzanwendungen ändern sich fortlaufend. In diesen Umgebungen wäre der Verlust mehrerer Stunden an Daten in der Regel nicht akzeptabel. Durch die Kombination aus vollständigen Sicherungen und Binary Logs lässt sich der Datenbestand nahezu ohne Datenverlust wiederherstellen.

SQL-Dumps spielen dagegen ihre Stärken überall dort aus, wo einzelne Datenbanken oder Tabellen unabhängig vom gesamten Server gesichert oder übertragen werden sollen. Sie eignen sich hervorragend für Entwicklungs- und Testumgebungen, für Datenmigrationen, zur Archivierung oder für den Export einzelner Kundendatenbanken. Auch bei kleineren Installationen mit geringem Änderungsaufkommen stellt ein regelmäßiger SQL-Dump häufig eine ausreichend einfache und zuverlässige Lösung dar.

In professionellen IT-Umgebungen werden beide Verfahren deshalb nicht als Konkurrenz betrachtet, sondern als sich ergänzende Bestandteile einer ganzheitlichen Backup-Strategie. Während Infrastruktur-Backups die kontinuierliche Absicherung des gesamten Datenbankservers gewährleisten, ermöglichen SQL-Dumps eine flexible Sicherung einzelner Datenbanken und vereinfachen Wartungs- und Migrationsaufgaben erheblich.

Verwaltung von Client-Backups mit dem lnbrt Backup Tool

Neben der eigentlichen Backup-Strategie spielt auch die Verwaltung und Automatisierung von Sicherungen eine entscheidende Rolle. Gerade in Umgebungen mit mehreren Datenbankservern oder zahlreichen Kundendatenbanken steigt der administrative Aufwand für die Erstellung, Überwachung und Wiederherstellung von Backups erheblich.

Für diesen Anwendungsbereich bietet das lnbrt Backup Tool von Linetz eine Lösung zur Verwaltung logischer Datenbank-Backups. Das Werkzeug konzentriert sich bewusst auf Client-Backups und unterstützt die Erstellung sowie Wiederherstellung von SQL-Dumps für MariaDB, MySQL und PostgreSQL.

Da SQL-Dumps auf Datenbank- oder Tabellenebene arbeiten, eignet sich das lnbrt Backup Tool insbesondere für Szenarien, in denen einzelne Datenbanken gezielt gesichert, archiviert oder zwischen Systemen migriert werden sollen. Die erzeugten Dumps können unabhängig vom zugrunde liegenden Server verwaltet und bei Bedarf selektiv wiederhergestellt werden.

Ein weiterer Vorteil besteht darin, dass sich Backup- und Restore-Prozesse zentral organisieren lassen. Wiederkehrende Sicherungsaufgaben können automatisiert werden, wodurch der manuelle Verwaltungsaufwand reduziert und die Durchführung regelmäßiger Backups vereinfacht wird. Im Wiederherstellungsfall lassen sich einzelne Datenbanken oder – abhängig vom Inhalt des SQL-Dumps – auch spezifische Tabellen gezielt zurückspielen, ohne den gesamten Datenbankserver wiederherstellen zu müssen.