Wer seine Datenbanken und Microservices nur einmal täglich nachts um 23:00 Uhr sichert, geht im Ernstfall das Risiko von fast 24 Stunden Datenverlust ein. In diesem Erfahrungsbericht untersuche ich anhand unseres eigenen Proxmox- und Docker-Clusters die Schwachstellen gängiger Backup-Pipelines. Ich zeige, warum Live-Replikation kein Backup ersetzt und wie wir mit 30-Minuten-Dumps, Restic und dem KISS-Prinzip die Wiederherstellung im Handbetrieb auf unter 5 Minuten senken.
Es ist Dienstagabend, 22:45 Uhr. Grafana schlägt Alarm, der Uptime-Guard meldet DOWN, und in den Logs des Reverse-Proxys hagelt es 502-Bad-Gateway-Fehler. Ein kurzer Blick ins Terminal zeigt das Desaster: Eine SSD des Datenbank-Nodes ist ausgestiegen.
Die erste beruhigende Reaktion: „Kein Problem, wir haben ja automatisierte Backups! Die laufen jeden Abend um 23:00 Uhr sauber durch.“ Doch genau in diesem Moment wird die Mathematik unerbittlich: Das letzte erfolgreiche Backup liegt exakt 23 Stunden und 45 Minuten zurück. Sämtliche Projektdaten, Redaktionsinhalte, Automatisierungsabläufe oder Zugangsdaten eines ganzen Tages sind spurlos verschwunden.
RPO vs. RTO: Der feine Unterschied zwischen Ausfallzeit und Datenverlust
In der Praxis werden zwei Kennzahlen ständig verwechselt, obwohl sie völlig unterschiedliche Risiken beschreiben:
- RTO (Recovery Time Objective – Ausfallzeit): Wie lange dauert es, bis die Anwendung nach einem Crash wieder erreichbar ist? Wenn Docker-Container per Skript in 15 Minuten neu aufgebaut werden, beträgt die RTO 15 Minuten.
- RPO (Recovery Point Objective – Datenverlust): Wie viele Daten verliere ich maximal zwischen dem Crash und dem letzten Sicherungspunkt? Wer nur nachts um 23:00 Uhr sichert, hat ein RPO von 24 Stunden.
Eine niedrige RTO von 15 Minuten nützt nichts, wenn das RPO 24 Stunden beträgt und man Nutzern erklären muss, warum alle Einträge eines Tages gelöscht sind.
Die drei großen Mythen der Datenbank-Sicherung
Bevor wir Architekturen vergleichen, müssen drei weit verbreitete Irrtümer ausgeräumt werden:
1. „Ich brauche kein Backup, ich nutze Master-Replica-Streaming!“
Eine Echtzeit-Spiegelung auf einen zweiten Server schützt hervorragend gegen den Ausfall einer einzelnen Festplatte. Führt jedoch ein Entwickler oder Skript versehentlich ein DROP TABLE users; aus, wird dieser Befehl innerhalb von 50 Millisekunden auf die Replica übertragen. Nach einer Zehntelsekunde sind die Daten auf beiden Systemen gelöscht. Replikation ist Ausfallsicherheit, kein Backup.
2. „Ich jage einfach Restic jede Stunde über mein Postgres-Verzeichnis!“
Wenn ein Backup-Tool über das aktive Datenverzeichnis (/var/lib/postgresql/data) einer laufenden Datenbank läuft, während im Speicher Blöcke modifiziert werden, ist das Ergebnis im Notfall oft korrupt (Hot-Backup-Problem). PostgreSQL bricht beim Starten mit Checksummen-Fehlern ab.
3. „Je komplexer das Backup-System, desto sicherer bin ich.“
Das Gegenteil ist wahr. Verteilte Enterprise-Systeme mit magischen Verschlüsselungs-Tokens und proprietären Encodern scheitern am häufigsten im Ernstfall. Je mehr Abhängigkeiten ein Restore hat, desto wahrscheinlicher versagt er unter Stress.
Der 3-Uhr-nachts-Handbetrieb-Test
Stell dir vor: Es ist 03:15 Uhr morgens. Du bist müde, dein Kopf dröhnt, der Hauptserver ist tot. Du sitzt vor einem jungfräulichen Terminal auf einem frischen Linux-Server.
Der Test lautet: Bist du in der Lage, deine Datenbank mit einfachen Standard-Befehlen (psql, zcat, restic) ohne Spezialsoftware oder GUI-Tools innerhalb von 5 Minuten manuell wiederherzustellen?
Das KISS-Prinzip (Keep It Simple, Stupid) ist hierbei die Lebensversicherung.
Die Strategien im Härtetest
In unserem Cluster (bestehend aus Proxmox-Hosts, Debian-Gästen und Docker-Containern für Redaktionssystem, Zugangsverwaltung, Automatisierung und Web-Statistik) haben wir verschiedene Ansätze bewertet:
| Strategie | Handbetrieb (KISS) | RPO (Datenverlust) | RTO (Restore-Zeit) | Bewertung |
|---|---|---|---|---|
| Nächtliches File-Backup | Schlecht (Riskant) | 24 Stunden | 30 Minuten | Nicht empfohlen |
| PG-Dump (30m) + Restic | 10 / 10 (Reines SQL) | 30–60 Minuten | < 5 Minuten | Top-Empfehlung |
| Litestream (SQLite) | 9 / 10 (1 Befehl) | < 1 Sekunde | < 2 Minuten | Empfehlung (SQLite) |
| WAL-G / pgBackRest | 6 / 10 (Komplex) | < 1 Minute | 15–30 Minuten | Nur für Groß-DBs |
| Master-Replica Only | 4 / 10 (Kein Backup) | < 1 Sekunde | < 2 Minuten | Kein Backup-Ersatz |
Strategie A: PG-Dump im 30-Minuten-Takt + Restic (Der Gewinner)
Ein leichtes Skript führt alle 30 bis 60 Minuten ein komprimiertes pg_dumpall | gzip in einen lokalen Ordner aus. Restic holt sich diesen Ordner alle 4 Stunden ab und schiebt ihn verschlüsselt weg. Da Restic deduplizierend arbeitet, verbrauchen die häufigen Dumps kaum zusätzlichen Cloud-Speicher.
Strategie B: Litestream für SQLite (Zugangsverwaltung & Verfügbarkeitsprüfung)
Für Dienste auf SQLite-Basis ist Litestream die beste Wahl. Es klinkt sich in das WAL-Log ein und streamt jede Änderung pro Sekunde verschlüsselt auf ein S3-Bucket oder NAS. Das RPO liegt bei unter 1 Sekunde.
Das praxiserprobte Best-Practice Setup
Das Skript für den 30-Minuten-Dump (/opt/scripts/db-quickdump.sh):
#!/bin/bash
set -euo pipefail
BACKUP_DIR="/opt/backups/postgres"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"
docker exec -t app-postgres pg_dumpall -U app | gzip > "$BACKUP_DIR/pg_dump_$TIMESTAMP.sql.gz"
find "$BACKUP_DIR" -name "pg_dump_*.sql.gz" -mmin +180 -delete
Einbindung in die Crontab (crontab -e):
*/30 * * * * /opt/scripts/db-quickdump.sh >/dev/null 2>&1
Der Wiederherstellungs-Befehl im Handbetrieb
Im Ernstfall auf der frischen Linux-Maschine:
restic restore latest --include /opt/backups/postgres --target /tmp/restore
Mit einem einzigen Befehl wird die Datenbank vollständig eingespielt:
zcat /tmp/restore/opt/backups/postgres/pg_dump_*.sql.gz | docker exec -i app-postgres psql -U app -d app
In unter 2 Minuten steht das System auf dem Stand der letzten 30 Minuten.
Quellen
- PostgreSQL Global Development Group, Continuous Archiving and Point-in-Time Recovery (PITR) Dokumentation, abgerufen 2026-08-09. Link
- Litestream.io, Streaming Replication for SQLite, abgerufen 2026-08-09. Link
- Restic Documentation, Deduplication and Repository Security, abgerufen 2026-08-09. Link
Transparenz: Der Beitrag beschreibt Erfahrungen aus dem eigenen Betrieb; konkrete Dienste, Adressen und Zugangsdaten werden bewusst nicht genannt. Alle Projekte sind selbstfinanziert, es bestehen keine bezahlten Kooperationen. Der Artikel wurde mit KI-Unterstützung (Claude) recherchiert und geschrieben; die verlinkten Quellen wurden geprüft, die redaktionelle Verantwortung liegt bei Marco Fuhrmann.