Projekt F: Datensicherung & Wiederherstellung

Quelle: VM 100 (ubuntu-server-01, 52 GB) Ziel: Samsung T7, 1 TB, ext4 Zeitplan: täglich 03:00, Snapshot-Modus, zstd Aufbewahrung: 7 täglich / 4 wöchentlich / 3 monatlich Stand: 15.10.2026

Kurzfazit: Das Backup lief seit Februar 2026 automatisch – bis die SSD voll war. Seit dem 26.07.2026 wurde kein Backup mehr erfolgreich erstellt, ohne dass es auffiel. Ursache war eine fehlende Aufbewahrungsregel. Nach Analyse, Bereinigung und Einführung einer Retention-Policy laufen die Backups wieder; ein isolierter Restore-Test hat die Wiederherstellbarkeit bestätigt.

1. Ziel

Automatisierte, tägliche Sicherung der produktiven Ubuntu-VM (Website, Reverse Proxy, Monitoring).
Backup-Ziel getrennt vom Systemdatenträger: externe SSD.
Nachweis der Wiederherstellbarkeit durch einen Restore-Test.

2. Umsetzung

2.1 Externe SSD einbinden

Die SSD wird per UUID eingebunden. nofail verhindert, dass der Host ohne angeschlossene SSD nicht bootet.

# /etc/fstab
UUID=739426fe-ac22-4133-9de1-b14ffcaef317 /mnt/Backupp ext4 defaults,nofail 0 2

2.2 Proxmox-Storage

is_mountpoint 1 sorgt dafür, dass Proxmox nur schreibt, wenn die SSD wirklich gemountet ist. Ohne diese Option würde ein Backup bei fehlender SSD unbemerkt auf die Systemplatte geschrieben.

# /etc/pve/storage.cfg
dir: Backupp
        path /mnt/Backupp
        content backup
        is_mountpoint 1

2.3 Backup-Job

# /etc/pve/jobs.cfg (Ausgangszustand)
vzdump: backup-0c95bee8-4301
        schedule 03:00
        compress zstd
        mode snapshot
        storage Backupp
        vmid 100

Der Snapshot-Modus sichert die VM im laufenden Betrieb – die Website bleibt während des Backups erreichbar.

3. Störung: Backups schlagen unbemerkt fehl

3.1 Symptom

Bei der Überprüfung im Oktober lagen im Backup-Verzeichnis für die letzten Wochen nur noch Logdateien, aber keine Sicherungsarchive (.vma.zst). Das jüngste Archiv stammte vom 26.07.2026.

3.2 Analyse

# Log des nächtlichen Jobs (15.10.2026)
INFO:   8% (4.4 GiB of 52.0 GiB) in 10s
ERROR: vma_queue_write: write error - Broken pipe
INFO: aborting backup job
ERROR: Backup of VM 100 failed - vma_queue_write: write error - Broken pipe

# Belegung der Backup-SSD
$ df -h /mnt/Backupp
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       916G  915G     0 100% /mnt/Backupp

3.3 Ursache

Keine Aufbewahrungsregel: Der Job hatte keine prune-backups-Einstellung. Jede Nacht kam ein neues Archiv (4–10 GB) hinzu, keines wurde gelöscht – rund 120 Archive seit Februar.
Platte voll: Ab einem bestimmten Punkt brach jeder Job nach wenigen Sekunden ab.
Keine Wahrnehmung: Proxmox versuchte, Fehlermails direkt vom Heimanschluss zuzustellen. Der Mailanbieter lehnte diese ab (fehlender PTR-Eintrag der privaten IP); die Mails blieben in der lokalen Warteschlange.

4. Lösung

4.1 Alte Backups bereinigen

Zuerst Vorschau mit --dry-run, um zu prüfen, welche Archive behalten bzw. gelöscht werden:

pvesm prune-backups Backupp --vmid 100 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --dry-run

Nach Prüfung der Liste (14 Archive behalten, übrige entfernt) dieselbe Bereinigung ohne --dry-run ausgeführt.

4.2 Aufbewahrungsregel dauerhaft setzen

pvesh set /cluster/backup/backup-0c95bee8-4301 \
  --prune-backups keep-daily=7,keep-weekly=4,keep-monthly=3

Ab jetzt entfernt Proxmox nach jedem Backup automatisch ältere Archive.

	Vorher	Nachher
Belegung SSD	915 GB (100 %)	126 GB (15 %)
Archive	ca. 120	14
Retention	keine	7 / 4 / 3

4.3 Verifikation: manuelles Backup

$ vzdump 100 --storage Backupp --mode snapshot --compress zstd
INFO: archive file size: 10.17GB
INFO: Finished Backup of VM 100 (00:02:20)
INFO: Backup job finished successfully

5. Restore-Test

Risikobewertung: Der Thin-Pool local-lvm war zu 70 % belegt. Ein Restore dorthin hätte ihn füllen können – mit Schreibfehlern auch für die produktive VM 100. Deshalb wurde der Test auf einem temporären Storage auf der Backup-SSD durchgeführt.

5.1 Vorgehen

Temporären Directory-Storage restore-test auf der SSD anlegen.
Jüngstes Archiv als neue VM 999 wiederherstellen; --unique 1 vergibt eine neue MAC-Adresse.
Netzwerk trennen (link_down=1), bevor die VM startet: Die Kopie hat dieselbe IP wie das Produktivsystem und würde sonst einen Konflikt verursachen.
VM starten, über die Konsole anmelden und Inhalte prüfen.
VM und temporären Storage wieder entfernen.

pvesm add dir restore-test --path /mnt/Backupp/restore-test \
  --content images --is_mountpoint /mnt/Backupp
qmrestore <archiv>.vma.zst 999 --storage restore-test --unique 1
qm set 999 --name restore-test --onboot 0
qm set 999 --net0 "virtio=…,bridge=vmbr0,firewall=1,link_down=1"
qm start 999

5.2 Ergebnis

# Restore
total bytes read 55835164672, sparse bytes 28280025088 (50.6%)
→ 52 GB Disk in 97 Sekunden wiederhergestellt

Die wiederhergestellte VM bootete fehlerfrei. Laut Bootlog starteten SSH, Docker und alle sieben Container; die Anmeldung über die Proxmox-Konsole war erfolgreich. cloudflared schlug erwartungsgemäß fehl – ein Beleg dafür, dass die Netzwerktrennung griff und die Kopie nicht mit der Live-Website kollidierte.

Nächster Ausbauschritt: Beim nächsten Restore-Test zusätzlich Inhalte direkt in der Konsole prüfen (Website-Dateien, docker ps).

Nachweise

Bootvorgang der wiederhergestellten VM 999 in der Proxmox-Konsole

VM 999 (restore-test) startet aus dem Backup: SSH, Docker und alle Container laufen, cloudflared scheitert wegen getrenntem Netzwerk.

Erfolgreiche Anmeldung an der wiederhergestellten VM (15.10.2026).

5.3 Aufräumen

qm stop 999 && qm destroy 999 --purge
pvesm remove restore-test

6. Lessons Learned

Ein Backup ohne Überwachung ist kein verlässliches Backup. Der Job war „aktiv“, hat aber monatelang nichts gesichert.
Retention gehört zur Einrichtung, nicht in die Nacharbeit. Kapazität muss von Anfang an geplant werden.
Erst Vorschau, dann löschen: --dry-run vor jeder Bereinigung.
Restore-Tests isoliert durchführen: eigener Storage, getrenntes Netzwerk, keine Auswirkung auf Produktion.

7. Offene Punkte

3-2-1 noch nicht vollständig: Aktuell existieren Produktivsystem + Kopie auf der SSD. Eine Offsite-Kopie fehlt noch.
Benachrichtigung: Zustellung über SMTP-Relay des Mailanbieters statt Direktversand.
Regelmäßiger Restore-Test, z. B. quartalsweise.

Repository auf GitHub öffnen