Backups mit Proxmox: Job, Aufbewahrung und der Restore-Test
Ein Backup ist erst dann ein Backup, wenn man weiß, dass man es zurückspielen kann. Bis dahin ist es nur eine Hoffnung in Dateiform. Dieser Beitrag beschreibt einen einfachen, aber vollständigen Ablauf für Container und Datenbanken.
Grundregel 3-2-1
- 3 Kopien der Daten (Original + 2 Backups),
- auf 2 verschiedenen Medien,
- davon 1 an einem anderen Ort.
Eine Sicherung auf derselben Platte oder demselben Host schützt vor Bedienfehlern und kaputten Updates, aber nicht vor Plattendefekt, Feuer oder einem Angreifer, der den Host übernimmt.
Backup-Job in Proxmox
Unter Datacenter → Backup legt man einen Job an:
| Einstellung | Beispiel | Warum |
|---|
| Zeitplan | täglich 03:00 | wenig Last, Ergebnis am Morgen prüfbar |
| Modus | snapshot | Container läuft weiter, kurze Konsistenzphase |
| Kompression | zstd | schnell und kompakt |
| Aufbewahrung | 7 täglich, 4 wöchentlich, 3 monatlich | älter wird automatisch gelöscht |
| Benachrichtigung | bei Fehlern | ein stiller Fehlschlag ist das gefährlichste Szenario |
Von Hand für einen einzelnen Container (ID 101):
vzdump 101 --mode snapshot --compress zstd --storage local
ls -lh /var/lib/vz/dump/
Speicherbedarf abschätzen
Ein Container mit 24 GB Root-Dateisystem, der nur zu einem Bruchteil gefüllt ist, ergibt ein komprimiertes Backup von etwa 0,4 GB. Bei der Aufbewahrung 7 + 4 + 3 = 14 Archive:
14 Archive × 0,4 GB ≈ 5,6 GB pro Container
Bei vier Containern sind das gut 22 GB. Wächst die Datenbank, wächst jedes Archiv mit. Den Speicher also gelegentlich mit df -h kontrollieren und die Aufbewahrung notfalls kürzen.
Datenbanken zusätzlich als Dump sichern
mariadb-dump --single-transaction --routines --triggers --databases appdb > appdb-$(date +%F).sql
sha256sum appdb-*.sql > SHA256SUMS
--single-transaction liefert bei InnoDB einen konsistenten Stand, ohne die Tabellen zu sperren. Die Prüfsumme merkt später, wenn eine Datei beim Kopieren beschädigt wurde:
sha256sum -c SHA256SUMS
Backups sind sensibel. Sie enthalten Konfigurationsdateien mit Zugangsdaten und Passwort-Hashes. Nicht in Cloud-Sync-Ordner, nicht per E-Mail, Rechte auf 700/600, nach Gebrauch löschen oder verschlüsselt ablegen.
Der Restore-Test
Mindestens nach jeder größeren Änderung, sonst alle paar Monate: ein Backup in einen neuen Container zurückspielen. Niemals blind über das Original.
pct restore 999 /var/lib/vz/dump/vzdump-lxc-101-2026_09_01-03_00_00.tar.zst --storage local-lvm
pct set 999 --net0 name=eth0,bridge=vmbr0,ip=10.0.0.199/24,gw=10.0.0.1
pct start 999
- Neue ID und neue IP vergeben, sonst gibt es zwei Container mit gleicher Adresse.
- Prüfen: Startet der Container? Laufen Webserver und Datenbank? Sind die aktuellen Daten da (letzter Eintrag, letzte Datei)?
- Dauer notieren. Das ist die Antwort auf „Wie lange sind wir im Ernstfall weg?“.
- Test-Container danach wieder löschen:
pct stop 999; pct destroy 999.
Was ein Restore-Test typischerweise aufdeckt
- Das Backup ist leer oder unvollständig, weil ein Verzeichnis nicht im Job war.
- Ein Passwort oder Schlüssel, der zur Wiederherstellung nötig ist, liegt nur im gesicherten System.
- Die Wiederherstellung dauert länger als gedacht (große Archive, langsame Platte).
- Konfigurationen sind an feste IP-Adressen gebunden und müssen angepasst werden.
Checkliste
- Job läuft nach Zeitplan und meldet Fehler.
- Aufbewahrung ist gesetzt und der Speicher reicht.
- Eine Kopie liegt außerhalb des Hosts (anderer Server, externer Speicher, Proxmox Backup Server).
- Restore wurde einmal komplett getestet und die Dauer notiert.
- Backups sind vor unbefugtem Zugriff geschützt.
Nicht das Backup zählt, sondern die Wiederherstellung. Was nie zurückgespielt wurde, ist ungetestet.