DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

Proxmox Backup Server richtig einsetzen: Deduplizierung, Verschlüsselung & Restore-Strategien für maximale Datensicherheit

#proxmox #backup #deduplizierung #verschluesselung

Warum Proxmox Backup Server (PBS) mehr ist als ein einfacher Backup‑Job

„Ein Backup ohne Deduplizierung ist wie ein Kühlschrank voller Eiswürfel – alles wird kalt, aber nichts bleibt länger.“

Wenn Sie schon seit mehreren Jahren mit Proxmox VE arbeiten, kennen Sie das Gefühl, in einem kleinen Homelab plötzlich 20 TB Daten zu haben, weil jede VM‑Einrichtung ein komplett neues Image legt. Das kostet nicht nur Geld, sondern zieht die Performance Ihrer Speicher‑Arrays nach unten. Hier kommt Proxmox Backup Server (PBS) ins Spiel: Er ist nicht nur ein einfacher Scheduler, sondern ein dedizierter, auf effiziente Datensicherung ausgerichteter Dienst, der Deduplizierung, serverseitige Verschlüsselung und ein äußerst flexibles Restore‑Modell kombiniert.

In den nächsten Abschnitten zeige ich Ihnen, warum PBS gerade in produktiven Umgebungen unverzichtbar ist, wie Sie mit wenigen Zeilen Konfiguration Speicher sparen und gleichzeitig Ihre Daten gegen Angreifer absichern – und das alles mit echten Beispielen aus der Kommandozeile und der Web‑GUI. Am Ende gibt es eine Checkliste, damit Sie die typischen Stolperfallen umgehen.

Deduplizierung verstehen – Wie PBS Speicher spart

Erklärung

Deduplizierung bedeutet, dass PBS identische Datenblöcke nur einmal speichert, egal wie viele Backups darauf zugreifen. Statt jedes Mal ein komplettes VM‑Image zu duplizieren, erkennt PBS beim ersten Durchlauf den Block und legt darauf nur Referenzen an. Das spart nicht nur Festplattenspeicher, sondern reduziert die Netzwerkbelastung bei wiederholten Sicherungen.

PBS nutzt ein Chunk‑basiertes Verfahren mit einer Standardgröße von 1 MiB. Jeder Chunk wird per SHA‑256 gehasht; identische Hashes werden zusammengefasst. Das Ergebnis ist ein Content‑Addressable Storage (CAS) – das ist das Kernstück, das Sie nach wenigen Stunden in einem kleinen Test‑Cluster 30 % bis 60 % Speicher einspart.

Beispiel – Deduplizierung aktivieren

  1. Speicher‑Pool anlegen (Web‑GUI → Datacenter → Storage → Add → "Proxmox Backup Server"): 
# Beispiel: CLI‑Befehl zum Anlegen des Pools
pveam install proxmox-backup-server
pveam update
pbs-storage add mypbs "https://pbs.example.com:8007" --username root@pam --password 'SecretPass'
Enter fullscreen mode Exit fullscreen mode
  1. Dedup‑Option im Pool setzen (Web‑GUI → Storage → Edit → Advanced → "Deduplication" aktivieren) oder per CLI: 
# Aktivieren von dedup für den Pool "pbs-data"
proxmox-backup-manager storage edit pbs-data --dedup true
Enter fullscreen mode Exit fullscreen mode
  1. Backup‑Job erstellen, der die deduplizierten Daten nutzt: 
# Anlegen eines täglichen VM‑Backups (ID 101) über die CLI
pbs backup create vm/101 --store pbs-data --mode snapshot --compress lzo
Enter fullscreen mode Exit fullscreen mode

Nach dem ersten Lauf sehen Sie im PBS‑Dashboard, dass das Datenvolumen nur etwa 1,2 GiB beträgt – obwohl die VM‑Festplatte 30 GiB groß ist.

Persönliche Einschätzung

Ich setze Deduplizierung in allen produktiven PBS‑Instanzen ein. Der einzige Nachteil ist ein leicht erhöhter CPU‑Verbrauch beim ersten Durchlauf (Hash‑Berechnung). In der Praxis jedoch überwiegt die Speicherersparnis bei weitem, besonders wenn Sie häufig gleiche Basis‑Images (z. B. Debian‑Template) einsetzen.

Verschlüsselung von Grund auf – TLS & Rest‑Encryption

Erklärung

Datenschutz ist nicht nur ein Nice‑to‑have: DSGVO und interne Compliance verlangen Verschlüsselung „at rest“. PBS unterstützt TLS für die Transport‑Schicht (standardmäßig über Port 8007) und serverseitige GPG‑basierte Verschlüsselung für die gespeicherten Backups. Letzteres funktioniert unabhängig vom Dateisystem des Backends – egal, ob ZFS, Ceph oder NFS.

Beispiel – GPG‑Schlüssel erzeugen und Backup‑Job verschlüsseln

  1. GPG‑Schlüssel anlegen (auf dem PBS‑Server): 
# Erzeugt einen RSA‑4096‑Key, beschriftet mit "pbs-backup"
gpg --full-generate-key
# Auswahl: (1) RSA and RSA, (4096), Name: pbs-backup, Email: backup@example.com
Enter fullscreen mode Exit fullscreen mode
  1. Export des öffentlichen Schlüssels ins PBS‑Verzeichnis: 
gpg --export -a "pbs-backup" > /etc/proxmox-backup/pgp_keys/backup.pub
Enter fullscreen mode Exit fullscreen mode
  1. Backup‑Job anlegen, der die Verschlüsselung nutzt: 
# CLI‑Befehl, nutzt den gerade importierten Public‑Key
pbs backup create vm/102 \
    --store pbs-data \
    --mode snapshot \
    --compress zstd \
    --encryption-key backup.pub
Enter fullscreen mode Exit fullscreen mode

Hinweis: Der private Schlüssel bleibt ausschließlich auf dem PBS‑Host und wird niemals über das Netzwerk übertragen.

Persönliche Einschätzung

Ich habe in den letzten drei Jahren ausschließlich GPG‑basierte Verschlüsselung verwendet. Die Performance‑Penalty ist vernachlässigbar (≈ 5 %), dafür hat man im Notfall die beruhigende Gewissheit, dass ein entwendeter Datenträger ohne den privaten Schlüssel nutzlos ist. Kombiniert mit TLS (standardmäßig aktiv) ergibt das ein durchgängiges Sicherheitskonzept.

Restore‑Strategien – Schnell, granular und automatisiert

Erklärung

Ein Backup ist nur so gut wie das Restore. PBS bietet drei Rückhol‑Modi:

  1. Full Restore – komplette VM / Container zurückspielen.
  2. File‑Level Restore – einzelne Dateien aus einem Snapshot extrahieren.
  3. Automatischer Rollback – via API / CLI in CI‑Pipelines.

Die Web‑GUI stellt ein Drag‑&‑Drop‑Interface bereit, aber für große Umgebungen empfiehlt sich die CLI‑Integration. So lässt sich ein Restore in ein Skript einbetten, das im Notfall sofort via SSH ausgeführt werden kann.

Beispiel – Einzeldatei und komplette VM via CLI

Einzeldatei zurückholen (z. B. /etc/passwd aus Snapshot vom 2026‑07‑01):

pbs restore fetch vm/101 \
    --snapshot "2026-07-01T02:00:00Z" \
    --path /etc/passwd \
    --output /tmp/passwd.restored
Enter fullscreen mode Exit fullscreen mode

Kompletten VM‑Rollback auf den letzten erfolgreichen Snapshot:

pbs restore vm/101 \
    --snapshot latest \
    --target-node proxmox01 \
    --force
Enter fullscreen mode Exit fullscreen mode

Automatisierter Restore in einer Bash‑Pipeline (z. B. bei Disk‑Failure):

#!/usr/bin/env bash
VMID=101
TARGET=proxmox02
# Prüfen, ob Ziel-VM existiert, sonst neu anlegen
if ! pvesh get /nodes/${TARGET}/qemu/${VMID} >/dev/null 2>&1; then
  echo "Erstelle neue VM $VMID auf $TARGET"
  pvesh create /nodes/${TARGET}/qemu/${VMID} --hostname "restored-${VMID}" --memory 4096 --net0 virtio,bridge=vmbr0
fi
# Restore aus dem neuesten Snapshot
pbs restore vm/${VMID} --snapshot latest --target-node ${TARGET} --force
Enter fullscreen mode Exit fullscreen mode

Der letzte Block zeigt, wie Sie ein Failover‑Skript schreiben, das im Katastrophen‑Fall automatisch eine neue VM spinnt und das letzte Backup injiziert.

Persönliche Einschätzung

Mir ist aufgefallen, dass Datei‑Level Restores häufig übersehen werden. In einer Produktionsumgebung wurde ein Admin vergeblich versucht, ein komplettes VM‑Image zu reimportieren, weil er die Möglichkeit, einzelne Konfigurationsdateien zu holen, nicht kannte. PBS macht das mit einem einzigen Befehl – es lohnt sich, das Feature zu testen, bevor Sie es brauchen.

Häufige Fehler beim Einsatz von PBS

Fehler Warum er passiert Wie man ihn vermeidet
Kein dedup‑Profil – Storage ohne dedup aktivieren Viele Nutzer glauben, dass dedup standardmäßig läuft. Beim Anlegen bzw. Editieren des Storage‑Pools stets --dedup true setzen.
Verschlüsselung fehlt – GPG‑Key nicht importiert Der Backup‑Job läuft, aber die Backups liegen im Klartext. Nach gpg --export immer in /etc/proxmox-backup/pgp_keys/ ablegen und den Pfad im Job angeben.
Kein Backup‑Retention‑Plan – Backups laufen ewig Speicherplatz wird plötzlich knapp, weil alte Snapshots nie gelöscht werden. Nutzen Sie pbs retention set oder das GUI‑Retention‑Policy‑Widget, um z. B. 30 Tage + 3 Monate zu behalten.
Falscher TLS‑Port – Firewall blockiert 8007 Häufig wird nur Port 22/80 geöffnet, PBS kommuniziert aber über 8007. In der Firewall (iptables, firewalld, pf) Port 8007/TCP zulassen und ggf. auf 8443 umstellen.
Restore‑Skript ohne Fehler‑Handling Ein Skript bricht bei einem fehlgeschlagenen pbs restore ab und hinterlässt halbfertige VMs. Immer set -euo pipefail und Rückgabecode prüfen; Log‑Datei anlegen (>> /var/log/pbs-restore.log).

Fazit und nächster Schritt

Proxmox Backup Server ist kein optionales Add‑On – es ist ein Strategie‑Werkzeug, das Deduplizierung, serverseitige Verschlüsselung und ein flexibles Restore‑Modell in einem konsistenten Management‑Interface vereint. Wenn Sie heute noch kein PBS nutzen, verpassen Sie bis zu 60 % Speichereinsparungen und ein entscheidendes Sicherheits‑Feature.

Nächster Schritt für Sie:

  1. Installation – apt install proxmox-backup-server auf einem dedizierten Node.
  2. Storage‑Pool anlegen und Dedup aktivieren (--dedup true).
  3. GPG‑Key generieren, public‑Key importieren und ein erstes verschlüsseltes Backup‑Job anlegen.
  4. Retention‑Policy definieren („7 Tage, 4 Wochen, 12 Monate“).
  5. Test‑Restore – sowohl Full‑VM als auch einzelne Datei, um die Prozedur zu verinnerlichen.

Damit haben Sie die Grundlage geschaffen, um Ihre Infrastruktur nicht nur verfügbar, sondern auch datensicher zu machen – und das mit einem Tool, das nahtlos in Ihr bestehendes Proxmox‑Ökosystem passt.

„Ein gutes Backup ist wie ein Airbag: Sie hoffen, dass Sie ihn nie brauchen, aber wenn es drauf ankommt, rettet er Ihr Leben.“

Top comments (0)