Datenbankbackup
Datenbanken sind kein normales Backup-Ziel. Während du Dateien einfach kopieren kannst, ist eine Datenbank während des Betriebs in ständiger Bewegung. Transaktionen, geöffnete Verbindungen, Caches im RAM, Write-Ahead-Logs – wenn du einfach cp database.db backup.db machst, bekommst du mit hoher Wahrscheinlichkeit eine korrupte und unbrauchbare Kopie.
Diese Lektion zeigt, warum Datenbank-Backups eine eigene Disziplin sind, welche Verfahren es gibt (logisch vs. physisch, hot/warm/cold), wie Point-in-Time-Recovery funktioniert und welche Tools du für MySQL, PostgreSQL, MS SQL Server, Oracle und MongoDB kennst. Im FISI-Alltag begegnen dir Datenbank-Backups ständig.
1) Warum Datenbanken anders sind
Eine Datenbank ist nicht einfach eine Datei – sie ist ein lebendes System. Während du sie sichern willst, schreibt sie ständig: neue Bestellungen kommen rein, Logins werden eingetragen, Sessions verlängert, Logs geschrieben. Das macht ein einfaches Datei-Backup unbrauchbar.
Das Kernproblem ist die Konsistenz. Eine Transaktion in einer Datenbank umfasst oft mehrere Schreibvorgänge auf verschiedene Tabellen. Beispiel: eine Banküberweisung muss vom Konto A abbuchen und auf Konto B gutschreiben. Wenn du das Backup mittendrin nimmst, hast du den Abzug ohne die Gutschrift. Das Backup ist technisch lesbar – aber logisch falsch:
2) Zwei grundlegende Verfahren: logisch vs. physisch
Datenbank-Backups gibt's in zwei fundamental verschiedenen Geschmacksrichtungen. Beide haben ihre Berechtigung – meist nutzt man eine Kombination:
Logisches Backup: Die Datenbank wird in eine Reihe von SQL-Anweisungen exportiert – z.B. CREATE TABLE, INSERT INTO. Das Ergebnis ist eine Text-Datei, die du in jede passende DB-Version einspielen kannst. Tools: mysqldump, pg_dump, mongodump. Vorteile: portabel, lesbar, version-unabhängig. Nachteile: langsam, vor allem beim Restore großer Datenmengen.
Physisches Backup: Die Datenbank-Dateien selbst werden gesichert – die binären Daten- und Index-Dateien auf der Festplatte. Voraussetzung: die DB muss in einem konsistenten Zustand sein (oder spezielle Tools zur Hot-Sicherung verwendet werden). Vorteile: schnell, ressourcensparend. Nachteile: oft nicht zwischen DB-Versionen portierbar.
3) Hot, Warm und Cold Backup
Davon zu unterscheiden sind die Zustände, in denen die DB beim Backup sein darf:
4) Logisches Backup mit mysqldump
Das klassische Tool für MySQL/MariaDB ist mysqldump. Es liest die DB aus und schreibt SQL-Statements in eine Datei. Schauen wir uns ein typisches Beispiel an:
Wichtige Optionen erklärt: --single-transaction startet eine Transaktion, sodass mysqldump einen konsistenten Snapshot bekommt – ohne die Tabellen zu locken. Funktioniert nur mit InnoDB-Tabellen. --master-data=2 notiert die Binlog-Position als Kommentar – wichtig für Point-in-Time-Recovery. gzip komprimiert sofort, spart 70-90% Platz bei SQL-Dumps.
Nachteil von mysqldump bei großen DBs: bei mehreren hundert GB dauert sowohl Dump als auch Restore Stunden. Dann greift man zu physischen Verfahren wie Percona XtraBackup oder MySQL Enterprise Backup.
5) Logisches Backup mit pg_dump (PostgreSQL)
PostgreSQL hat pg_dump als Pendant. Sehr ähnlich, ein paar Eigenheiten:
Das Custom-Format (-Fc) ist binär, komprimiert und unterstützt Parallel-Restore über pg_restore -j. Ein 100-GB-Restore, der sequenziell 4 Stunden braucht, kann mit 8 parallelen Workern auf eine knappe Stunde runter.
6) Point-in-Time-Recovery (PITR)
Das mächtigste DB-Backup-Konzept ist Point-in-Time-Recovery: du kannst die Datenbank auf jeden beliebigen Zeitpunkt zurücksetzen – nicht nur auf gesicherte Stände. Das ermöglicht extrem niedrige RPO-Werte:
Das Prinzip: jede Datenbank schreibt ein Transaction Log (in MySQL: Binary Log oder binlog, in PostgreSQL: Write-Ahead Log oder WAL, in Oracle: Redo Log). Wenn du diese Logs kontinuierlich sicherst, kannst du nach einem Disaster genau vorgehen:
mysqlbinlog alle Logs bis 14:34:59 in die DB einspielen. Die DROP-DATABASE-Aktion wird ausgelassen.7) MySQL Binary Logs aktivieren
Für PITR in MySQL musst du das Binary Log einschalten. In /etc/my.cnf bzw. /etc/mysql/my.cnf:
Nach Aktivierung wachsen /var/log/mysql/mysql-bin.000001, .000002 etc. Diese Files zusätzlich ins Backup. Bei PostgreSQL ist das WAL-Archiving das Pendant, konfiguriert über archive_mode = on und archive_command.
8) Replikation als Backup-Strategie
Eine weitere Methode für sehr niedrige RPO: Replikation. Ein zweiter DB-Server hält eine ständig aktuelle Kopie. Bei Ausfall des Primary übernimmt der Replica.
- MySQL Replication: Master schickt Binary Logs an Slaves, die sie replay'en. Async oder semi-sync möglich.
- PostgreSQL Streaming Replication: Standby-Server bekommt WAL-Stream vom Primary. Sync-Modus für RPO = 0.
- MS SQL Always On Availability Groups: Microsoft-Lösung mit automatischem Failover.
- Galera Cluster: Multi-Master für MySQL/MariaDB, synchrone Replikation.
Wichtig: Replikation ist kein vollständiges Backup-Ersatz. Wenn du auf dem Master ein DROP TABLE ausführst, wird das innerhalb von Millisekunden auf die Replicas repliziert. Du brauchst trotzdem klassische Backups plus Replikation für die volle 3-2-1-Strategie. Replikation schützt vor Hardware-Ausfall, nicht vor logischen Fehlern.
9) DB-Backup für verschiedene Systeme
Jedes DB-System hat seine eigenen Backup-Tools. Hier ein Überblick:
10) Strategien-Vergleich
Wann benutzt du welche Methode? Eine Übersicht:
11) Datenbank-Backups in Cloud-Diensten
Wenn du eine Datenbank in der Cloud nutzt (AWS RDS, Azure SQL, Google Cloud SQL), kümmert sich der Anbieter um viele Backup-Details. Typische Features:
- Automatic Backups: täglich automatisch, mit konfigurierbarer Retention (1-35 Tage bei AWS RDS)
- Point-in-Time-Recovery: Restore auf jeden Zeitpunkt innerhalb der Retention
- Manual Snapshots: explizit erstellte Snapshots, beliebig lange aufbewahrt
- Cross-Region Replication: Snapshots in andere Region kopieren – für Off-Site
- Read Replicas: skalierbare Replikation, auch für DR nutzbar
Aber Vorsicht: Cloud-Backups sind nicht automatisch sicher. Wenn dein AWS-Account gesperrt wird oder kompromittiert ist, sind auch alle Snapshots weg. Best Practice: zusätzlich Backups außerhalb des Cloud-Accounts (z.B. zu Backblaze oder Hetzner exportieren) – nach 3-2-1.
12) Was sichert man, was nicht?
Eine produktive Datenbank hat oft mehrere DBs/Schemas, Caches, Logs. Was gehört wirklich ins Backup?
| Element | Backup? | Begründung |
|---|---|---|
| Produktivdatenbank | ✓ Ja | Klar: das ist der Kern |
| Schema (Tabellen, Indexes) | ✓ Ja | Ohne Schema nutzlos |
| Stored Procedures, Functions | ✓ Ja | Anwendungslogik, nicht trivial neu zu schreiben |
| Trigger, Events, Views | ✓ Ja | Teil der Anwendungslogik |
| User & Berechtigungen | ✓ Ja | Sonst nach Restore keine Zugriffe möglich |
| System-DB (mysql.*, postgres) | ✓ Ja | Enthält User-Tabelle und Konfiguration |
| Konfiguration (my.cnf, postgresql.conf) | ✓ Ja | Außerhalb der DB – separat sichern |
| Temp-Tabellen, Sessions | ✗ Nein | Werden ohnehin neu erstellt |
| Query-Cache | ✗ Nein | Wird bei DB-Start neu aufgebaut |
| Slow-Log, General-Log | ~ Je nach | Für Analyse interessant, nicht kritisch |
13) Typische Anti-Patterns bei DB-Backups
Auch erfahrene DBAs machen Fehler. Diese Anti-Patterns sind häufig:
- Datei-Backup einer laufenden DB ohne Vorbereitung: ergibt korrupte Backups, oft nicht restorebar
- Backup nur via Replikation: schützt nicht vor logischen Fehlern (gelöschte Daten werden repliziert)
- Binary Logs nicht aktiviert: kein PITR möglich, hoher RPO
- Binary Logs nicht außerhalb gesichert: bei Server-Ausfall sind sie weg
- Backup direkt auf gleichem Server: bei Hardware-Defekt alles weg
- Berechtigungen nicht mit-gesichert: nach Restore können User nicht zugreifen
- Restore nie getestet: oft kommt erst beim Notfall heraus dass das Backup nicht funktioniert
- Cleartext-Backups: Passwörter und Kundendaten unverschlüsselt – DSGVO-Verstoß
- Kein Versionsschutz: ein Backup-Job mit neuem Bug überschreibt die nächsten Backups als kaputt
14) Best Practices zusammengefasst
Eine Checkliste für Datenbank-Backups:
- Hot Backup statt Cold (außer bei kleinen Wartungsfenstern)
- Sowohl logisches als auch physisches Backup, gestaffelt
- Binary/WAL/Redo Logs aktivieren für PITR
- Logs zusätzlich sichern, nicht nur auf dem DB-Server
- Konfigurationsdateien separat sichern
- Berechtigungen explizit mit-sichern
- Backups verschlüsseln (AES-256), besonders bei personenbezogenen Daten
- Restore regelmäßig testen – mindestens quartalsweise
- Off-Site-Kopie nach 3-2-1
- Backups dokumentieren: was, wann, wo, wie wiederherstellen?
- Backup-Monitoring: schlägt Alarm wenn Backup fehlschlägt
- Retention-Strategie planen (GFS oder ähnlich, siehe L3)
Zusammenfassung
Datenbank-Backups sind speziell: einfaches Datei-Kopieren ergibt korrupte Backups, weil DBs ständig in Bewegung sind. Konsistenz (ACID) muss gewahrt werden. Zwei Verfahren: logisch (SQL-Dump, portabel, langsam – mysqldump, pg_dump, mongodump) und physisch (Datei-Snapshot, schnell, version-gebunden – Percona XtraBackup, pg_basebackup). Drei Zustände: Hot (DB läuft, Standard), Warm (read-only), Cold (DB offline). Point-in-Time-Recovery: Voll-Backup + Transaction Logs (binlog/WAL/Redo) ermöglicht Restore auf beliebigen Zeitpunkt, RPO < 1 Sekunde. Replikation (MySQL Async/Semi-Sync, PG Streaming, MS Always On, Galera) für niedrigste RPO – aber kein Ersatz für klassische Backups (Logikfehler werden repliziert). Cloud-DBs (AWS RDS, Azure SQL) haben eingebaute Backups, aber Account-Risiko bleibt. Sichern: Daten + Schema + Stored Procs + Trigger + User + Konfiguration. Best Practices: Logs aktivieren, Backups verschlüsseln, Konfig sichern, Restore testen, off-site nach 3-2-1.