Datenbank-Backup: Verfahren, Rotation und Wiederherstellung

Ein Datenbank-Backup unterscheidet sich grundlegend von einer Dateisicherung: Eine laufende Datenbank schreibt ständig, und eine einfache Dateikopie ist inkonsistent. Dieser Artikel beschreibt die Verfahren, ihre Unterschiede und den Ablauf, der sich in der Praxis bewährt hat.

Warum Dateikopien nicht genügen

Eine Datenbankdatei besteht aus vielen Teilen: Datendateien, Protokolldateien, Indexstrukturen. Zwischen zwei Lesevorgängen kann sich die Datei ändern. Eine Kopie „von außen“ enthält dann Zustände aus verschiedenen Zeitpunkten – die Datenbank ist beschädigt.

Drei Auswege gibt es:

  1. Logischer Export: Die Datenbank wird durch Abfragen ausgelesen und als Text bzw. Skript geschrieben. Konsistent, portabel, aber langsam bei großen Datenmengen.
  2. Physische Sicherung mit Unterstützung der Datenbank: Werkzeuge wie pg_basebackup, xtrabackup oder mariabackup arbeiten mit der Datenbank zusammen und erzeugen einen konsistenten Stand.
  3. Momentaufnahme des Speichers: Bei Dateisystem- oder Speicherschnappschüssen (LVM, ZFS, Storage-Snapshots) wird die Datenbank kurz eingefroren (freeze), der Schnappschuss erstellt und wieder freigegeben. Sehr schnell, aber an die Infrastruktur gebunden.

Logische Sicherung: der Alltagsfall

# PostgreSQL
#   -Fc  eigenes Format, komprimiert, selektive Wiederherstellung moeglich
pg_dump -Fc -h db.example.org -U app -d appdb -f /srv/backup/appdb_$(date +%F).dump

#   Parallele Sicherung grosser Datenbanken (mehrere Prozesse)
pg_dump -Fd -j 4 -h db -U app -d appdb -f /srv/backup/appdb_$(date +%F)

#   Gesamtserver inklusive Rollen, Tabellenraeume, Zuweisungen
pg_dumpall -h db -U postgres -f /srv/backup/alle_$(date +%F).sql

# MySQL / MariaDB
#   --single-transaction: konsistenter Stand ohne Sperre (nur InnoDB!)
mysqldump -h db --single-transaction --quick --routines --events \
  --triggers --skip-ssl -u app -p'geheim' appdb | \
  gzip > /srv/backup/appdb_$(date +%F).sql.gz

#   Struktur und Daten getrennt (grosser Vorteil fuer Vergleiche)
mysqldump --no-data  ... appdb > /srv/backup/appdb_schema.sql
mysqldump --no-create-info ... appdb > /srv/backup/appdb_daten.sql

# SQLite (Datei einfach kopieren - mit der richtigen Methode)
sqlite3 daten.db ".backup '/srv/backup/daten_$(date +%F).db'"
#   NICHT einfach cp verwenden, wenn gleichzeitig geschrieben wird!
#   .backup nutzt die interne Sicherungsfunktion.

# MongoDB
mongodump --uri="mongodb://user:geheim@db:27017/appdb" --out=/srv/backup/mongo_$(date +%F)

Konsistenz und Wiederholbarkeit

Drei Punkte entscheiden über die Brauchbarkeit einer Sicherung:

  • Einheitlicher Zeitpunkt: Bei mehreren Datenbanken oder Tabellen muss der Stand zusammenpassen. Bei parallelen Läufen aus einem Datenbestand: entweder alle gleichzeitig sichern oder eine Reihenfolge mit Berücksichtigung der Beziehungen einhalten.
  • Vollständigkeit der Objekte: Bei MySQL vergisst man leicht --routines (gespeicherte Prozeduren), --events und --triggers. Ohne sie funktioniert die Anwendung nach der Wiederherstellung nicht.
  • Rechte und Rollen: Ein Dump enthält die Daten, nicht die Benutzerkonten. Bei pg_dumpall sind sie dabei; sonst gehören sie separat dokumentiert.

Aufbewahrung und Rotation

# Bewaehrtes Muster: Grossvater-Vater-Sohn
#   taeglich:  die letzten 14 Sicherungen
#   woechentlich: die letzten 8 Wochen
#   monatlich:  die letzten 12 Monate
#   jaehrlich:  dauerhaft

# Einfache Rotation mit find
find /srv/backup/tag -name '*.dump' -mtime +14 -delete
find /srv/backup/woche -name '*.dump' -mtime +56 -delete

# Mit Hardlinks sparen (rsnapshot-aehnlich): unveraenderte Dateien
# werden nicht kopiert, sondern verlinkt.

# WAS IMMER GILT: eine Kopie ausser Haus. 3-2-1-Regel.
#   mindestens 3 Kopien, auf 2 verschiedenen Medien, 1 davon extern.
#   Ein Brand oder Diebstahl im Serverraum nimmt sonst alles mit.

Wiederherstellung üben

Der einzige Test, der zählt: In eine Testinstanz zurückspielen und prüfen, ob die Anwendung läuft.

# 1. Testdatenbank anlegen
createdb -h db-test -U app appdb_probe

# 2. Wiederherstellen
pg_restore -h db-test -U app -d appdb_probe -j 4 /srv/backup/appdb_2026-09-26.dump

# 3. Inhalt pruefen - nicht nur "es lief durch"
psql -h db-test -U app -d appdb_probe -c "
  SELECT 'kunden' AS tabelle, count(*) FROM kunden
  UNION ALL SELECT 'bestellungen', count(*) FROM bestellungen
  UNION ALL SELECT 'positionen',  count(*) FROM positionen;
"

# 4. Geschaeftslogik pruefen, nicht nur Zeilenzahlen
#    Stimmen die Summen? Sind Fremdschluessel intakt?
#    Laeuft eine Abfrage, die die Anwendung taeglich braucht?
psql -h db-test -U app -d appdb_probe -c "
  SELECT k.id, k.name, sum(b.betrag) AS umsatz
  FROM kunden k JOIN bestellungen b ON b.kunde_id = k.id
  GROUP BY k.id, k.name ORDER BY umsatz DESC LIMIT 5;
"

# 5. Anwendung gegen die Testdatenbank starten - der eigentliche Test

# 6. Aufraeumen
dropdb -h db-test -U app appdb_probe

Kennzahlen, die festgelegt werden müssen

  • RPO (Recovery Point Objective): Wie viel Datenverlust ist hinnehmbar? Ein RPO von einer Stunde erfordert stündliche Sicherungen oder kontinuierliche Protokollarchivierung.
  • RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung dauern? Ein RTO von 15 Minuten ist mit einem Dump nicht erreichbar – dafür braucht es Replikation oder Speicherschnappschüsse.
  • Aufbewahrungsfristen: Aus rechtlichen Gründen und aus praktischen (ein Fehler, der vor Wochen entstand, wird manchmal erst später bemerkt).

Beide Werte bestimmen das Verfahren. Wer einen RTO von Minuten braucht, aber nur nächtliche Dumps hat, hat ein Konzept, das nicht zum Ziel passt.

Größere Umgebungen

Ab einer gewissen Größe reichen Kommandozeilenwerkzeuge nicht mehr:

  • pgBackRest: Parallele Sicherung, inkrementelle Sicherungen, Aufbewahrungsregeln, Point-in-Time-Wiederherstellung, Prüfung der Sicherungen. Für PostgreSQL der De-facto-Standard.
  • XtraBackup / Mariabackup: Physische Sicherung für MySQL/MariaDB mit inkrementellen Stufen.
  • Barman: Verwaltung von Sicherungen und Archiven für PostgreSQL, mit Wiederherstellungsautomatisierung.
  • Repositoriumswerkzeuge: restic oder BorgBackup zusätzlich zum Datenbank-Werkzeug – für die Dateien des Systems und die Dumps. Deduplizierung spart dabei erheblich Speicher, weil sich Dumps stark ähneln.

Häufige Fehler

  1. Nicht getestet. Der wichtigste Punkt. Eine ungeprüfte Sicherung ist eine Annahme.
  2. Kein Platz für die Wiederherstellung. Die Datenbank ist größer als der freie Speicher auf dem Zielsystem – das wird erst im Notfall bemerkt.
  3. Zu lange Laufzeit. Ein Dump, der länger dauert als das Intervall, läuft in den nächsten hinein.
  4. Unvollständige Objekte. Prozeduren, Auslöser, Ereignisse, Rechte vergessen.
  5. Keine Meldung bei Fehlschlag. Der Auftrag läuft seit Wochen nicht mehr, und niemand merkt es. Ein unabhängiger Beobachter, der das Alter der Sicherung prüft, ist die Lösung.
  6. Geheimnisse woanders. Die Datenbank ist verschlüsselt, der Schlüssel liegt aber auf demselben System – fällt das System aus, ist beides verloren. Schlüssel gehören getrennt.
  7. Eine einzige Kopie. 3-2-1-Regel umsetzen.
  8. Wiederherstellung nicht geübt. Im Notfall fehlt die Zeit zum Ausprobieren der Befehle.

Verwandte Grundlagen: Backup-Test, Backup-Strategie für KMU, restic, PostgreSQL im Betrieb.