Proxmox Backup Server richtig aufsetzen

Der Proxmox Backup Server (PBS) sichert VMs und Container inkrementell auf Blockebene, dedupliziert über alle Gäste hinweg und verschlüsselt auf Wunsch clientseitig. Für eine Handvoll Proxmox-Hosts ist er das Werkzeug, das den größten Unterschied macht, vor allem, weil eine Wiederherstellung damit tatsächlich ein Knopfdruck ist.

Dieser Beitrag beschreibt die Einrichtung und die vier Stellen, an denen man sich später ärgert, wenn man sie jetzt überspringt.

Wo der PBS steht#

Nicht auf demselben Host wie die Gäste, die er sichert. Das klingt selbstverständlich und wird trotzdem regelmäßig gemacht, weil es bequem ist.

Sinnvolle Varianten, in aufsteigender Sicherheit:

Eigene VM auf einem anderen Proxmox-Host, schon deutlich besser als lokal.
Eigene Maschine im selben Netz, überlebt den Ausfall eines Hosts.
Eigene Maschine an einem anderen Standort, überlebt auch den Ausfall des Standorts.

Für die dritte Kopie im Sinne von 3-2-1 reicht auch ein zweiter PBS, auf den der erste synchronisiert. Dazu unten mehr.

Installation#

PBS gibt es als eigenes ISO oder als Paket auf einem bestehenden Debian:

echo "deb http://download.proxmox.com/debian/pbs trixie pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs-no-subscription.list

curl -fsSL https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg \
  -o /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg

apt update && apt install -y proxmox-backup-server

Oberfläche danach auf Port 8007 (nicht 8006 wie PVE).

Datastore anlegen#

Ein Datastore ist ein Verzeichnis, in dem PBS seine Chunks ablegt. Auf einem eigenen Dateisystem, nicht auf der Systempartition:

# Beispiel: ZFS-Pool aus zwei Platten, gespiegelt
zpool create -o ashift=12 backup mirror /dev/sda /dev/sdb
zfs set compression=lz4 backup
zfs create backup/store

proxmox-backup-manager datastore create store1 /backup/store
proxmox-backup-manager datastore list

Warum gespiegelt

Ein Datastore ohne Redundanz ist der Punkt, an dem eine einzelne defekte Platte alle Sicherungen aller Maschinen mitnimmt. Der Spiegel kostet eine Platte und erspart genau dieses Szenario. Prüfsummen kommen bei ZFS obendrauf: Ein stiller Lesefehler fällt beim scrub auf, nicht erst beim Restore.

Verschlüsselung und der Schlüssel, der alles entscheidet#

PBS verschlüsselt clientseitig, also auf dem Proxmox-Host, bevor die Daten den Rechner verlassen. Der Backup-Server sieht dann nur noch verschlüsselte Chunks. Das ist der Grund, warum ein PBS bei einem fremden Anbieter stehen darf.

Auf dem PVE-Host:

proxmox-backup-client key create /root/pbs.key --kdf scrypt
proxmox-backup-client key show /root/pbs.key

# Zusätzlich einen ausdruckbaren Papierschlüssel erzeugen
proxmox-backup-client key paperkey /root/pbs.key --output-format text > /root/pbs-paperkey.txt

Ohne diesen Schlüssel sind alle Sicherungen wertlos

Das ist keine Formulierung zur Abschreckung, sondern die Funktionsweise. Es gibt keine Hintertür, keinen Support-Weg, keine Wiederherstellung. Der Schlüssel gehört an mindestens zwei Orte außerhalb der gesicherten Infrastruktur: in einen Passwortmanager (siehe Vaultwarden) und als Papierausdruck an einen physisch anderen Ort. Wer nur eine Kopie auf dem Host hat, den er sichert, hat die Verschlüsselung gegen sich selbst gerichtet.

PVE-Host mit dem PBS verbinden#

Auf dem PBS einen eigenen Benutzer statt root@pam anlegen, mit genau den Rechten, die ein Sicherungslauf braucht:

proxmox-backup-manager user create backup@pbs --password '...'
proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id backup@pbs

DatastoreBackup darf schreiben und lesen, aber nicht löschen. Das ist der Unterschied, der zählt, wenn der PVE-Host übernommen wird: Ein Angreifer mit den Zugangsdaten kann dann keine alten Sicherungen vernichten.

Fingerabdruck des PBS holen (auf dem PBS):

proxmox-backup-manager cert info | grep Fingerprint

Dann auf dem PVE-Host unter Datacenter → Storage → Add → Proxmox Backup Server eintragen, oder per Kommandozeile:

pvesm add pbs pbs-store1 \
  --server pbs.example \
  --datastore store1 \
  --username backup@pbs \
  --password \
  --fingerprint aa:bb:cc:... \
  --encryption-key /root/pbs.key

Aufbewahrung und Garbage Collection#

Zwei getrennte Mechanismen, die oft verwechselt werden:

Prune entscheidet, welche Sicherungsstände in der Liste bleiben. Es löscht keine Daten, nur Verweise.

Garbage Collection räumt anschließend die Chunks weg, auf die kein Stand mehr zeigt. Erst dadurch wird Platz frei.

# Aufbewahrung: letzte 7 Tage, 4 Wochen, 6 Monate, 2 Jahre
proxmox-backup-manager prune-job create daily-prune \
  --store store1 --schedule 'daily' \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2

# Aufräumen, danach
proxmox-backup-manager garbage-collection start store1

Warum die Platte nicht leerer wird

Wer nur prune laufen lässt und sich über gleichbleibenden Füllstand wundert: Die GC fehlt. Sie sollte als eigener Zeitplan laufen, üblicherweise wöchentlich und zeitlich nach den Prune-Läufen. Zusätzlich hat PBS eine Schonfrist von rund 24 Stunden für frische Chunks, direkt nach einem Prune wird also nichts frei.

Verify: prüfen, ob das Gesicherte lesbar ist#

Ein Verify-Lauf liest die Chunks und vergleicht Prüfsummen. Das ist der Unterschied zwischen „das Backup ist gelaufen“ und „das Backup ist gültig“.

proxmox-backup-manager verify-job create weekly-verify \
  --store store1 --schedule 'sat 02:00' \
  --ignore-verified true --outdated-after 30

--ignore-verified überspringt Stände, die kürzlich geprüft wurden; --outdated-after 30 prüft sie nach 30 Tagen erneut. So bleibt die Laufzeit beherrschbar, und trotzdem wird jeder Stand regelmäßig angefasst.

Auf ein zweites Ziel spiegeln#

Ein Sync-Job zieht die Daten eines Datastores auf einen zweiten PBS, bevorzugt an einem anderen Ort. Das ist die „1“ in 3-2-1.

Auf dem Ziel-PBS:

proxmox-backup-manager remote create quelle1 \
  --host pbs.example --auth-id sync@pbs --password --fingerprint aa:bb:cc:...

proxmox-backup-manager sync-job create sync-store1 \
  --store store1-remote --remote quelle1 --remote-store store1 \
  --schedule 'daily 05:00'

Wichtig ist die Richtung: Das Ziel holt. Ein übernommener Quell-Host kann dann nicht auf das Ziel schreiben oder dort löschen.

Den Restore üben, bevor man ihn braucht#

Der Teil, den fast alle überspringen und der einzige, der wirklich beweist, dass das alles funktioniert.

Kleine Übung (fünf Minuten): Eine einzelne Datei aus einem Container-Backup zurückholen. In der PBS-Oberfläche unter Content → Backup auswählen → File Restore. Funktioniert für LXC direkt und für VMs, sofern das Dateisystem erkannt wird.

Große Übung (halber Nachmittag, einmal im Jahr):

# Was liegt vor?
proxmox-backup-client snapshot list --repository backup@[email protected]:store1

# Eine VM unter neuer ID zurückspielen, ohne die produktive anzufassen
qmrestore pbs-store1:backup/vm/100/2026-06-20T02:00:00Z 999 --storage local-lvm

Die zurückgespielte Maschine startest du in einem isolierten Netz (Brücke ohne Uplink) und prüfst: Bootet sie, sind die Daten aktuell, laufen die Dienste? Danach löschen. Das Ergebnis ist eine belastbare Aussage darüber, wie lange eine Wiederherstellung wirklich dauert, eine Zahl, die man kennen sollte, bevor jemand danach fragt.

Zum Nachschlagen#

Aufgabe	Befehl
Zustand aller Datastores	`proxmox-backup-manager datastore list`
Läufe der letzten Zeit	`proxmox-backup-manager task list`
Belegung und Deduplizierungsfaktor	in der Oberfläche unter Datastore → Summary
Schlüssel anzeigen	`proxmox-backup-client key show /root/pbs.key`
Manueller Sicherungslauf	`vzdump 100 --storage pbs-store1 --mode snapshot`

Und die eine Frage, die zwischendurch beantwortet sein sollte: Wo liegt der Verschlüsselungsschlüssel, wenn dieser Standort komplett weg ist?