Datenbank sichern und wirklich zurückspielen

Bei Dateien ist eine Sicherung eine Kopie. Bei Datenbanken nicht: Während kopiert wird, schreibt der Dienst weiter. Eine unbedachte Kopie enthält deshalb Tabellen aus verschiedenen Momenten, sie lässt sich zurückspielen und ist trotzdem falsch.

Drei Verfahren lösen das unterschiedlich, und keins davon ist für alles richtig.

Die drei Verfahren#

	Dump (logisch)	Snapshot (Dateisystem)	Point-in-Time
Was liegt vor	SQL-Text	Abbild der Dateien	Basis + fortlaufendes Journal
Konsistent	ja (mit der richtigen Option)	ja, wenn atomar	ja, auf die Sekunde
Rückspielen	langsam, Indizes werden neu gebaut	schnell	schnell, dann Journal nachfahren
Teilweise möglich	ja, einzelne Tabelle	nein	nein
Versionswechsel	ja	nein	nein
Platzbedarf	klein (komprimiert)	groß	mittel
Gut gegen	Fehler in der Anwendung, Umzug	Totalausfall	„vor der Löschung um 14:32“

Die meisten kleinen Installationen fahren richtig mit: täglicher Dump plus Snapshot der VM. Der Dump rettet eine versehentlich gelöschte Tabelle, der Snapshot rettet die Maschine.

Dump, richtig gemacht#

# PostgreSQL: eigenes Format, komprimiert, parallel rückspielbar
sudo -u postgres pg_dump -Fc -Z6 meineapp > /backup/meineapp-$(date +%F).dump

# MariaDB: eine Transaktion, damit alle Tabellen denselben Moment zeigen
mariadb-dump --single-transaction --quick --routines --events \
  --databases meineapp | gzip > /backup/meineapp-$(date +%F).sql.gz

Ohne --single-transaction ist der Dump nicht konsistent

Ein Dump ohne diese Option liest Tabelle für Tabelle, während die Anwendung weiterschreibt. Bestellungen können dann auf Positionen verweisen, die es im Dump nicht gibt. Der Fehler zeigt sich nicht beim Sichern und nicht beim Rückspielen, sondern erst, wenn jemand die Daten benutzt. Die Option wirkt nur bei InnoDB-Tabellen, MyISAM kann das nicht, ein weiterer Grund, sie umzustellen.

Rückspielen:

# PostgreSQL
sudo -u postgres pg_restore -d meineapp_neu -j 4 /backup/meineapp-2026-08-19.dump

# MariaDB
zcat /backup/meineapp-2026-08-19.sql.gz | mariadb

-j 4 bei PostgreSQL ist kein Detail: Der Indexaufbau ist der langsamste Teil, und er parallelisiert.

Point-in-Time: wenn eine Nacht zu viel Verlust ist#

Ein täglicher Dump bedeutet: Im Ernstfall fehlt alles seit dem Dump. Für einen Blog ist das hinnehmbar, für einen Shop nicht. Point-in-Time-Wiederherstellung schließt die Lücke, Basissicherung plus fortlaufendes Journal.

# PostgreSQL: Journal (WAL) fortlaufend wegschreiben
ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM SET archive_command = 'test ! -f /backup/wal/%f && cp %p /backup/wal/%f';
-- Neustart nötig; danach die Basissicherung:
pg_basebackup -D /backup/basis -Ft -z -P

# MariaDB: Binärprotokoll einschalten
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
expire_logs_days = 14

Der Preis: mehr Platz, mehr Betreuung, und das Journal muss woanders liegen als die Datenbank. Ein Journal auf derselben Platte hilft gegen genau nichts.

Die Zahl, die wirklich zählt#

Nicht die Größe der Sicherung, nicht die Dauer des Dumps: Wie lange dauert das Zurückspielen? Diese Zahl misst man einmal und schreibt sie auf.

# Auf einer Testmaschine, mit echter Sicherung:
time pg_restore -d test -j 4 /backup/meineapp-2026-08-19.dump

Aus der Zahl folgt das Verfahren, nicht umgekehrt. Braucht ein Dump-Restore vier Stunden und du kannst zwei verkraften, brauchst du Snapshots, kein größeres Sicherungslaufwerk.

Der Ernstfall ist selten der Plattenausfall

In der Praxis sind es: ein DELETE ohne WHERE, eine fehlerhafte Datenmigration, eine Anwendung, die nach einem Update Unsinn schreibt. In allen drei Fällen ist die Datenbank technisch gesund, der Snapshot der VM enthält also brav den kaputten Zustand. Dagegen hilft nur eine Sicherung, die alt genug ist, und das Wissen, wann es passiert ist.

Prüfen, dass die Sicherung überhaupt etwas enthält#

Eine Sicherungsdatei existiert. Ob sie brauchbar ist, weiß man erst nach dem Öffnen:

# PostgreSQL: Inhaltsverzeichnis anzeigen, ohne zurückzuspielen
pg_restore -l /backup/meineapp-2026-08-19.dump | head -20

# MariaDB: enthält der Dump am Ende die Abschlusszeile?
zcat /backup/meineapp-2026-08-19.sql.gz | tail -3
# "Dump completed" fehlt = der Dump ist abgebrochen

Diese zwei Prüfungen gehören in das Sicherungsskript, direkt hinter das Erstellen. Sie kosten Sekunden und fangen den häufigsten stillen Fehler ab: eine volle Platte mitten im Dump.

Wohin die Sicherung gehört#

Nicht auf dieselbe Maschine. Nicht nur auf dieselbe Maschine. Der Rest, mehrere Ziele, ein Ziel außer Haus, Verschlüsselung, Aufbewahrung, steht in 3-2-1 in der Praxis. Für virtualisierte Umgebungen ergänzt der Proxmox Backup Server die Ebene darunter: Er sichert die ganze VM, während der Dump die Daten sichert. Beides zusammen ist die Antwort, nicht eins davon.

Häufige Fragen#

Reicht ein Snapshot der VM?#

Gegen Maschinenverlust ja. Gegen einen Anwendungsfehler nicht, weil er den Fehler mitsichert. Und beim Zurückspielen bekommst du den Zustand „Stromausfall“, Datenbanken kommen damit klar, sauberer ist es trotzdem nicht.

Wie lange aufbewahren?#

Genug, um einen Fehler zu überleben, der erst spät auffällt. Eine verbreitete Staffelung: sieben tägliche, vier wöchentliche, zwölf monatliche. Wichtiger als die genaue Zahl ist, dass eine alte Sicherung existiert.

Kann ich im laufenden Betrieb sichern?#

Ja, mit den Optionen oben. Ohne sie ist die Kopie unbrauchbar, ohne dass es jemand merkt.

Was ist mit Replikation?#

Eine Nachbildung ist keine Sicherung: Ein DROP TABLE wird sauber mitrepliziert. Sie schützt gegen Hardwareausfall, nicht gegen Fehler.

Muss ich das Zurückspielen wirklich üben?#

Ja. Es ist der einzige Test, der die ganze Kette prüft, Datei, Vollständigkeit, Rechte, Version, Zeitbedarf. Einmal im Halbjahr, mit Datum notiert.

Kurz gesagt#

Dump plus Snapshot deckt die zwei häufigen Fälle ab.
--single-transaction bzw. -Fc, sonst ist die Sicherung nur scheinbar da.
Wiederherstellungszeit messen, nicht die Sicherungsgröße.
Point-in-Time erst, wenn eine Nacht Datenverlust zu viel ist und das Journal gehört woanders hin.
Replikation ist keine Sicherung. Ein Löschbefehl repliziert sich hervorragend.