Es gibt zwei Arten von Menschen, die mit Datenbanken arbeiten: solche, die schon einmal Daten verloren haben, und solche, die es noch werden. Festplatten sterben, Server brennen, Ransomware verschlüsselt, und ein einziges falsches DELETE ohne WHERE kann eine ganze Tabelle leeren. Ein durchdachtes Backup-Konzept ist deshalb keine Kür, sondern Pflicht. Dieser Artikel zeigt dir, welche Backup-Arten es gibt, wie du sie kombinierst und welchen Fehler fast alle machen.
Die wichtigste Wahrheit vorweg: Ein Backup ohne Restore-Test ist kein Backup
Bevor wir in Technik einsteigen, das Wichtigste: Ein Backup, das du nie zurückgespielt hast, ist im Grunde nur eine Hoffnung. Unzählige Betriebe haben im Ernstfall festgestellt, dass ihre Sicherung korrupt, unvollständig oder mit dem falschen Schlüssel verschlüsselt war. Nur ein erfolgreich getesteter Restore beweist, dass dein Backup funktioniert. Plane regelmäßige Wiederherstellungstests fest ein – das ist der Teil, den am meisten Leute überspringen und am bittersten bereuen.
Logische vs. physische Backups
Grundsätzlich unterscheidet man zwei Backup-Typen, die unterschiedliche Stärken haben.
Logisches Backup (Dump)
Ein logisches Backup exportiert die Datenbank in SQL-Befehle: eine Textdatei voller CREATE TABLE- und INSERT-Anweisungen, die die Datenbank von Grund auf wieder aufbauen. Bei MySQL erzeugst du das mit mysqldump, bei PostgreSQL mit pg_dump, und bei SQLite genügt der Befehl .dump oder schlicht das Kopieren der Datei.
- Vorteile: Menschenlesbar, portabel zwischen Versionen und sogar zwischen Systemen, einfach zu komprimieren, ideal für kleinere Datenbanken.
- Nachteile: Bei sehr großen Datenbanken langsam beim Erstellen und vor allem beim Zurückspielen, da jede Zeile einzeln eingefügt wird.
Physisches Backup
Ein physisches Backup kopiert die eigentlichen Datendateien der Datenbank auf Dateiebene (Snapshots, Kopien der Datendateien, Tools wie Percona XtraBackup für MySQL). Es sichert den Rohzustand auf der Festplatte statt einer SQL-Beschreibung.
- Vorteile: Sehr schnell bei großen Datenbanken, schnelle Wiederherstellung.
- Nachteile: Weniger portabel (oft an dieselbe Datenbankversion gebunden), nicht menschenlesbar, erfordert mehr Sorgfalt bei der Konsistenz.
Für die meisten kleinen bis mittleren Projekte ist das logische Backup der pragmatische Standard. Erst bei sehr großen, lastintensiven Datenbanken werden physische Backups unverzichtbar.
Voll, inkrementell, differenziell
Egal welcher Typ – Backups unterscheiden sich auch darin, wie viel sie jeweils sichern:
- Vollbackup: Sichert die komplette Datenbank. Einfach und vollständig, aber speicher- und zeitintensiv. Würde man es täglich machen, verbraucht es viel Platz.
- Inkrementelles Backup: Sichert nur die Änderungen seit dem letzten Backup (egal welcher Art). Klein und schnell, aber zum Wiederherstellen brauchst du das Vollbackup plus alle nachfolgenden Inkremente in der richtigen Reihenfolge.
- Differenzielles Backup: Sichert alle Änderungen seit dem letzten Vollbackup. Wächst über die Zeit, vereinfacht aber die Wiederherstellung (Vollbackup plus genau ein differenzielles).
Eine bewährte Praxis ist die Kombination: ein wöchentliches Vollbackup, ergänzt durch tägliche inkrementelle oder differenzielle Backups. So balancierst du Speicherbedarf und Wiederherstellungsaufwand.
Point-in-Time Recovery (PITR)
Was, wenn ein Mitarbeiter um 14:37 Uhr versehentlich eine wichtige Tabelle löscht und das nächste Backup von Mitternacht ist? Hier kommt Point-in-Time Recovery ins Spiel. Datenbanken wie MySQL und PostgreSQL führen ein Transaktionslog (Binary Log bzw. Write-Ahead Log), das jede einzelne Änderung protokolliert.
Mit PITR spielst du zunächst das letzte Vollbackup ein und wendest dann das Transaktionslog bis zu einem exakten Zeitpunkt an – etwa "Zustand um 14:36 Uhr, eine Minute vor dem Fehler". So minimierst du den Datenverlust auf Sekunden statt Stunden. PITR einzurichten ist etwas aufwendiger, aber für geschäftskritische Daten unverzichtbar.
Die 3-2-1-Regel
Die wohl bekannteste Backup-Faustregel ist simpel und wirkungsvoll:
- 3 Kopien deiner Daten (das Original plus zwei Backups)
- 2 verschiedene Speichermedien oder Technologien
- 1 Kopie außer Haus (offsite), idealerweise auch offline
Warum offsite? Ein Backup auf demselben Server hilft nicht, wenn der Server gestohlen wird oder abbrennt. Warum offline? Ransomware verschlüsselt zunehmend auch verbundene Backup-Laufwerke. Eine "kalte" Kopie, die nicht permanent erreichbar ist (Air Gap), schützt davor. Moderne Erweiterungen sprechen sogar von der 3-2-1-1-0-Regel: zusätzlich eine unveränderliche (immutable) Kopie und null Fehler beim Restore-Test.
Backups automatisieren
Ein manuelles Backup, an das du dich erinnern musst, wird irgendwann vergessen. Automatisiere alles. Unter Linux planst du Backups klassisch mit cron, unter Windows mit der Aufgabenplanung. Ein typischer Ablauf:
- Datenbank-Dump erstellen (z. B.
mysqldump) - Dump komprimieren (gzip/zstd) und mit Zeitstempel benennen
- Backup verschlüsseln
- An einen entfernten Speicherort übertragen (z. B. mit einem Sync-Tool)
- Alte Backups nach einer Aufbewahrungsregel löschen (Retention)
- Erfolg oder Misserfolg melden (Monitoring/Benachrichtigung)
Der letzte Punkt ist wichtig: Du musst aktiv benachrichtigt werden, wenn ein Backup fehlschlägt. Ein stillschweigend seit drei Wochen fehlgeschlagenes Backup ist eine tickende Zeitbombe.
Verschlüsselung nicht vergessen
Ein Datenbank-Backup enthält all deine sensiblen Daten – Kundeninformationen, Passwort-Hashes, Geschäftszahlen. Liegt es unverschlüsselt herum, ist es ein gefundenes Fressen für Angreifer und ein DSGVO-Problem. Verschlüssele Backups grundsätzlich, besonders bevor sie das Haus verlassen (Cloud, externe Festplatte).
Achte dabei auf die Schlüsselverwaltung: Wenn du den Schlüssel verlierst, ist auch das Backup verloren. Bewahre den Schlüssel getrennt vom Backup auf. Sichere, lange Schlüssel und Passwörter erzeugst du bequem mit einem Passwort-Generator; weitere nützliche Helfer findest du im Webtools-Bereich.
RTO und RPO: Die zwei Kennzahlen, die zählen
Profis planen Backups anhand zweier Größen:
- RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Ein RPO von einer Stunde bedeutet, dass du maximal eine Stunde an Daten verlieren darfst – also mindestens stündlich sichern musst.
- RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung dauern? Ein RTO von 30 Minuten heißt, dass dein System spätestens nach einer halben Stunde wieder laufen muss.
Diese beiden Zahlen bestimmen deine gesamte Strategie. Ein Hobby-Blog kommt mit täglichen Backups und einem RTO von Stunden aus. Ein Online-Shop braucht PITR, häufige Backups und schnelle Wiederherstellung.
Backups je nach Datenbanktyp
Die Werkzeuge unterscheiden sich je nach System. Bei SQLite ist das Backup besonders simpel: Die gesamte Datenbank ist eine Datei, die du (im Ruhezustand oder über den eingebauten Backup-Befehl) einfach kopierst. Bei MySQL nutzt du mysqldump für logische und Tools wie XtraBackup für physische Backups. Welcher Ansatz sich für dein Projekt eignet, hängt auch von der gewählten Datenbank ab – mehr dazu in unserem Vergleich SQLite vs. MySQL.
Häufige Fehler bei Backups
- Nie getestet: Der Klassiker. Restore nie ausprobiert, im Ernstfall funktioniert es nicht.
- Nur lokal gespeichert: Backup liegt auf demselben Server – bei Hardware-Ausfall oder Brand mit weg.
- Inkonsistente Snapshots: Datenbank während des Backups nicht sauber pausiert, Sicherung enthält halbe Transaktionen.
- Keine Überwachung: Fehlgeschlagene Backups bleiben unbemerkt.
- Schlüssel verloren: Verschlüsseltes Backup, aber der Schlüssel ist weg.
Häufige Fragen
Wie oft soll ich Backups machen?
Das hängt von deinem RPO ab – also davon, wie viel Datenverlust du verkraftest. Ein guter Startpunkt: tägliche Vollbackups plus Transaktionslog für PITR bei wichtigen Daten. Unkritische Daten reichen wöchentlich.
Wie lange soll ich Backups aufbewahren?
Eine verbreitete Staffelung ist: tägliche Backups für eine Woche, wöchentliche für einen Monat, monatliche für ein Jahr. So hast du sowohl kurzfristige als auch ältere Wiederherstellungspunkte, ohne unbegrenzt Speicher zu verbrauchen.
Reicht es, einfach die ganze Festplatte zu sichern?
Nicht zuverlässig. Eine laufende Datenbank schreibt ständig, und ein Festplatten-Snapshot kann mitten in einer Transaktion entstehen – das ergibt eine inkonsistente, möglicherweise unbrauchbare Kopie. Nutze die datenbankeigenen Backup-Mechanismen, die für Konsistenz sorgen.
Kann ich Backups verschlüsseln, ohne die Wiederherstellung zu erschweren?
Ja, solange du die Schlüsselverwaltung im Griff hast. Bewahre den Schlüssel sicher und getrennt auf, dokumentiere den Wiederherstellungsprozess und teste den Restore inklusive Entschlüsselung regelmäßig.