Datenbanksicherung: Wann ein Backup die Datenbank wirklich rettet
Datenbanksicherung: warum die Kopie der Dateien nicht reicht
Laut BSI-Lagebericht 2025 blieb die Zahl der beim BKA angezeigten Ransomware-Angriffe mit 950 weitgehend unverändert, 80 Prozent davon trafen kleine und mittlere Unternehmen. Gebraucht wird danach vor allem die Datenbank, also der Speicher, in dem eine Anwendung Kunden, Aufträge und Buchungen ablegt.
Eine Datenbanksicherung ist eine Kopie des Datenbestands, die einen in sich stimmigen Zeitpunkt festhält. Jeder Vorgang ist darin entweder vollständig abgeschlossen oder gar nicht enthalten. Sie entsteht mit den Werkzeugen des Datenbanksystems oder bei angehaltener Datenbank, umfasst neben den Daten auch Tabellenstruktur, Benutzer und Rechte und gilt erst dann als brauchbar, wenn sich aus ihr ein lauffähiger Stand wiederherstellen lässt.
Der halb geschriebene Vorgang
Ob eine Datenbanksicherung trägt, entscheidet sich schon beim Kopieren. Bucht eine Warenwirtschaft einen Auftrag, legt sie ihn an, senkt den Lagerbestand und erzeugt die Rechnung. Die Datenbank fasst das zu einer Transaktion zusammen, also zu einem Vorgang, der nur ganz oder gar nicht gilt. Eine Kopie auf Dateiebene kennt diese Klammer nicht. Läuft sie mitten in die Buchung hinein, enthält sie den Auftrag ohne die Änderung am Bestand.
Konsistente Sicherung im laufenden Betrieb
Konsistent heißt, dass die Sicherung einen Zustand zeigt, den es in der Datenbank tatsächlich gegeben hat. Laut der Dokumentation von PostgreSQL muss für eine brauchbare Kopie auf Dateiebene der Datenbankserver heruntergefahren sein, selbst das Sperren aller Verbindungen genügt nicht. Es bleiben zwei Wege. Entweder ruht die Anwendung während eines Sicherungsfensters, oder ein Verfahren der Datenbank selbst erzeugt im Betrieb einen stimmigen Stand.
Dateien, Postfächer und ganze Server fallen unter die allgemeine Datensicherung für Unternehmen. Eine Datenbanksicherung braucht darin ein eigenes Verfahren, weil die Datenbank ständig schreibt. Ein nächtliches Server-Backup erfasst sie nur als Sammlung von Dateien. Ob eine so entstandene Kopie zu einem lauffähigen Stand führt, zeigt allein die Rückspielung in eine getrennte Umgebung.
Datenbank-Backup: Verfahren im Vergleich
Welches Verfahren für die Datenbanksicherung passt, hängt an zwei Fragen. Wie wird gesichert, und wie viel ändert sich zwischen zwei Läufen? Die Antworten bestimmen, wie lange ein Datenbank-Backup später zurückgespielt wird und wie viel Arbeit seit dem letzten Lauf verloren geht. Replikation kommt nur als Abgrenzung vor.
Logische und physische Sicherung einer Datenbank
Ein logisches Datenbank-Backup schreibt den Inhalt als Befehle heraus, aus denen sich Tabellen und Datensätze neu aufbauen lassen, bei MySQL etwa mit mysqldump. Ein solches MySQL-Backup läuft auch auf einem anderen Server, dauert bei großen Beständen aber lange. Eine physische Sicherung kopiert dagegen die Speicherdateien samt Transaktionsprotokoll, in dem die Datenbank jede Änderung der Reihe nach mitschreibt. Sie ist schneller zurückgespielt und Grundlage für ein PostgreSQL-Backup, das per Point in Time Recovery auf einen frei gewählten Zeitpunkt zurückführen soll.
In die Kopie gehören auch Benutzerkonten, Rechte und Trigger. Sie entstehen in der Datenbankentwicklung und fehlen nach einer Wiederherstellung, wenn nur die Tabelleninhalte gesichert wurden.
Welche Sicherungsart passt zu welcher Änderungsrate?
Die drei Sicherungsarten sind aus der Welt der Dateien bekannt. An einer Datenbank verschiebt sich die Frage, weil sich dort ständig einzelne Datenblöcke ändern und nicht ganze Dateien. Je Art zählen Laufzeit, Aufwand beim Zurückspielen und der passende Bestand:
- Vollsicherung: lange Laufzeit, schnellste Rückspielung, kleine Bestände
- Differentielles Backup: wächst bis zur nächsten Vollsicherung, Rückspielung aus zwei Teilen
- Inkrementelles Backup: kürzeste Laufzeit, braucht die ganze Kette
- Protokollsicherung: läuft fortlaufend, braucht eine physische Basissicherung
Beim SQL-Server-Backup von Microsoft heißen die Varianten vollständige Sicherung, differenzielle Sicherung und Protokollsicherung. In einem Shop mit laufenden Bestellungen wächst ein differentielles Backup schnell auf die Größe einer Vollsicherung zu. Ob eine Software diese Arten bei der Datenbanksicherung beherrscht oder nur Dateien kopiert, ist deshalb das erste Kriterium beim Vergleich von Backup-Lösungen.
Wie die Sicherungskette die Rückspielung verlängert
Ein inkrementelles Backup ist nur zusammen mit allen Vorgängern bis zur letzten Vollsicherung brauchbar. Fehlt ein Glied, endet die Wiederherstellung an dieser Stelle. Jedes weitere Glied kostet beim Zurückspielen einen eigenen Schritt. Bei der Sicherung von Datenbanken mit großen Beständen verkürzt eine häufigere Vollsicherung die Kette, braucht aber mehr Speicher. Zwischen zwei Läufen hilft das Transaktionsprotokoll, sofern die Sicherungsart es mitnimmt.
Warum Datenbank-Replikation keine Sicherung ist
Eine Datenbank-Replikation hält eine zweite Datenbank ständig auf demselben Stand wie die erste. Das schützt vor dem Ausfall eines Servers, aber nicht vor einem Fehler in den Daten. Löscht ein fehlerhaftes Update tausend Kundensätze, löscht die Kopie sie Sekunden später mit. Replikation sichert Verfügbarkeit, aber keinen früheren Zustand. Sie ergänzt eine Datenbanksicherung und ersetzt sie nicht, und auch ein bestandener Failover Test belegt nichts über die Sicherung.
Datenbanksicherung nachweisen: allein die Rückspielung zählt
Eine Datenbanksicherung ist so viel wert wie die letzte gelungene Wiederherstellung aus ihr. Dieser Abschnitt behandelt, woran sich das erkennen lässt, wie oft ein Restore Test fällig ist und was der BSI IT-Grundschutz für Datenbanksysteme verlangt. Am Ende steht ein Konflikt, den keine Sicherungssoftware löst, nämlich Aufbewahrung gegen Löschpflicht.
Restore Test in einer getrennten Umgebung
Ein grüner Status im Sicherungsprogramm meldet einen fehlerfreien Lauf, über den Inhalt sagt er nichts. Das laufende Backup Monitoring erkennt abgebrochene und unvollständige Läufe. Ob der Inhalt zurückspielbar ist, zeigt sich erst, wenn IT-Verantwortliche das Backup testen. Beim Restore Test wird das Datenbank-Backup getrennt vom Produktivsystem eingespielt und die Anwendung darauf gestartet. Festgehalten wird nach jeder Testwiederherstellung:
❓ Startet die Datenbank ohne Reparaturmeldung?
❓ Stimmen die Datensätze mit dem Stand zum Sicherungszeitpunkt?
❓ Lassen sich Anmeldung und ein neuer Vorgang durchführen?
❓ Sind Benutzer, Rechte und Schnittstellen vollständig?
❓ Wie lange hat die Wiederherstellung gedauert?
Die Dauer zeigt, wie lange der Betrieb nach einem Ausfall ohne die Anwendung auskommen muss. Sie wird mit der zugesagten Wiederherstellungszeit verglichen. Die Wiederherstellung von Datenbanken dauert länger als das Kopieren, wenn Indizes neu aufgebaut und Protokolle nachgespielt werden.
Wie oft ein Restore Test fällig ist
Der Rhythmus richtet sich danach, wie oft sich die Umgebung ändert. Eine SQL-Datenbank sichern und die Kopie nie einspielen heißt, sich auf eine Annahme zu verlassen. Ein Backup testen ist deshalb nach jedem Update des Datenbanksystems fällig, nach einer Änderung am Sicherungsverfahren, nach einem Umzug auf neue Server und nach dem Wechsel des Dienstleisters. Dazwischen läuft der Wiederherstellungstest in einem festen Takt, der im Konzept steht.
Was fordert der BSI IT-Grundschutz für Datenbanksysteme?
Der Baustein APP.4.3 Relationale Datenbanken im IT-Grundschutz-Kompendium, Edition 2023, regelt das in der Basis-Anforderung A9. Verlangt sind regelmäßige Sicherungen des Datenbankmanagementsystems und der Daten. Vor dem Anlegen einer neuen Datenbank muss die Sicherung des Datenbanksystems erfolgen, und alle Transaktionen sollen jederzeit wiederherstellbar gesichert werden. Reicht der Platz nicht, sieht der Baustein ein erweitertes Konzept vor, etwa eine inkrementelle Sicherung. Die Wiederherstellungsparameter richten sich nach dem Schutzbedarf der Daten, mit Verweis auf den Baustein CON.3 zum Datensicherungskonzept.
Aufbewahrung und Löschpflicht im Konflikt
Eine Sicherung der Datenbank bewahrt auch Daten auf, die im laufenden System längst gelöscht sein müssen, etwa Bewerberdaten nach Ablauf ihrer Frist. Einzelne Datensätze lassen sich aus einer fertigen Sicherung kaum gezielt entfernen. Deshalb wird die Aufbewahrungsdauer jeder Datenbanksicherung auf das Löschkonzept abgestimmt, das auch die Fristen regelt.
Best Practices für die Wartung von Datenbanken
Zu den besten Praktiken für die Wartung von Datenbanken gehört, dass die Datenbanksicherung eine benannte Verantwortung hat und nicht nur ein Zeitplan im System ist. Dieser Abschnitt ordnet, was dafür schriftlich festgelegt wird und welche Größen die laufenden Kosten bestimmen.
Verantwortung, Intervall und Prüfrhythmus festhalten
Im Mittelstand Datenbanksicherung nebenbei zu erledigen, funktioniert, solange die Person im Betrieb ist, die das System eingerichtet hat. Fällt sie aus, fehlt ohne Dokumentation das Wissen, in welcher Reihenfolge ein Backup der Datenbank zurückgespielt wird. Ein kurzes Betriebsblatt hält deshalb fest:
- wer die Sicherung verantwortet und wer vertritt
- wann und wie oft gesichert wird
- welche Sicherungsart läuft und wo die Kopien liegen
- wie lange Sicherungen aufbewahrt werden
- wann der nächste Restore Test ansteht
Mit diesem Blatt kann auch jemand eine MySQL-Datenbank sichern und wiederherstellen, der das System nicht aufgebaut hat. Liegt der Betrieb bei einem Dienstleister, gehören diese Punkte in den Vertrag. Beim Softwarebetrieb und der Wartung einer Anwendung sind sie vereinbarte Leistung und keine mündliche Absprache.
Was die laufenden Kosten einer Sicherung treibt
Die Zahl der Datenbanken sagt über den Aufwand wenig. Eine kleine Datenbank mit vielen Buchungen macht mehr Sicherungsarbeit als eine große, die sich kaum ändert. Den Aufwand einer Datenbanksicherung bestimmen vier Größen, die sich vor jedem Angebot beziffern lassen:
- Datenvolumen, weil es Laufzeit und Speicher bestimmt
- Änderungsrate, weil sie Zahl und Größe der Folgeläufe bestimmt
- Aufbewahrungsdauer, weil jede Generation Speicher belegt
- zugesagte Wiederherstellungszeit, weil sie den Takt jedes Restore Tests vorgibt
Backup- und Wiederherstellungskonzepte für eine kritische Anwendung liegen deshalb am oberen Ende. TenMedia übernimmt bei Individualsoftware den Betrieb samt Sicherung von Code, Dateien und Datenbank, regelmäßig getesteter Wiederherstellung und drei Monaten Aufbewahrung, auch für Software anderer Entwickler. Beim Relaunch eines Datenbanksystems für ein Bildungsinstitut sichern automatisierte Backups und ein Monitoring mit Sentry den laufenden Betrieb auf MySQL.
