Proxmox Backup Server einrichten: Sicher sichern

Proxmox Backup Server richtet für Proxmox VE einen dedizierten Backup-Speicher ein, der Sicherungen dedupliziert ablegt, prüft und zu einem zweiten Server synchronisieren kann. Dieser Leitfaden führt von der Hardware-Entscheidung über Datastore und PVE-Anbindung bis zu Aufbewahrung, Prüfung und Wiederherstellungsprobe.

Stand: 27.10.2026

Auf einen Blick

• Installiere PBS vorzugsweise auf separater Hardware, nicht auf dem PVE-Hypervisor.
• Ein Datastore braucht ein passendes lokales Dateisystem; FAT ist nicht geeignet.
• Prune entfernt zunächst Metadaten, erst die Garbage Collection gibt nicht mehr referenzierte Chunks frei.
• Plane eine regelmäßige Verifikation und prüfe eine Wiederherstellung.
• Ein zweiter PBS kann Datastores per Sync Job an einen anderen Standort übernehmen.

Teil 1 – Planung

1. Die Ausgangslage und das Ziel

Mit Proxmox Backup Server einrichten schaffst Du einen zentralen Zielort für VM-, Container- und Host-Backups. Das Ziel ist nicht nur ein erfolgreicher Backup-Task, sondern ein nachvollziehbarer Ablauf: Daten landen auf getrenntem Speicher, werden auf Integrität geprüft und lassen sich bei Bedarf wiederherstellen.

PBS speichert Sicherungen in einem Datastore als Chunks. Dadurch können gleiche Datenblöcke wiederverwendet werden. Laut der Speicher-Dokumentation darf ein kompromittierter Backup-Client bereits vorhandene Backup-Daten nicht umschreiben. Das ersetzt jedoch weder getrennte Zugänge noch eine zweite Kopie an einem anderen Ort.

Warum ein separater Server wichtig ist

Installiere PBS nach Möglichkeit auf eigener physischer Hardware. Die Proxmox-Dokumentation rät davon ab, den Backup-Server direkt auf dem Hypervisor zu installieren: Fällt dieser Host aus, bleiben die Sicherungen auf einem getrennten Server erreichbar. Ein separater Rechner verringert außerdem die gemeinsame Fehlerdomäne von Compute, Betriebssystem und Backup-Speicher.

Als Orientierung nennt Proxmox für Produktion mindestens vier CPU-Kerne, 4 GiB RAM für Betriebssystem, Cache und PBS sowie zusätzlich mindestens 1 GiB RAM je TiB Speicher. Das sind Empfehlungen, keine Kapazitätsgarantie; Größe, Änderungsrate und Aufbewahrung bestimmen den tatsächlichen Speicherbedarf.

2. Voraussetzungen und Architektur

Für die ISO-Installation brauchst Du einen 64-Bit-Server, Netzwerk und einen USB-Stick mit mindestens 2 GB. Die ISO ist laut Proxmox der empfohlene Weg, weil sie Installer, Debian-Basis und Verwaltungswerkzeuge mitbringt. Alternativ lässt sich PBS auf einem vorbereiteten Debian installieren; dann verantwortest Du Partitionierung, Speicher und Netzwerk selbst.

Für die Verbindung darfst Du den Management-Port 8007 nur aus dem Verwaltungsnetz erreichbar machen. Öffne die Oberfläche danach über https://<PBS-IP-ODER-DNS>:8007. Veröffentliche sie nicht ungeschützt im Internet; wenn Du Reverse Proxy einsetzt, lies vorher den Beitrag zum sicheren Traefik-Homelab.

Teil 2 – Installation und Speicher

3. Proxmox Backup Server installieren

Lade die ISO von der offiziellen Download-Seite und ermittle vor dem Schreiben eindeutig den USB-Datenträger. Der folgende Befehl zeigt Datenträger; vergleiche Größe und Namen vor und nach dem Einstecken. Das verhindert, dass der falsche Datenträger überschrieben wird.

lsblk

Der USB-Stick erscheint zusätzlich. Prüfe seine Größe nochmals, denn der nächste Schritt überschreibt seinen gesamten Inhalt.

Schreibe die heruntergeladene ISO als Rohabbild auf den zuvor ermittelten Stick. Ersetze /dev/XYZ ausschließlich durch das ganze USB-Gerät, niemals durch eine Systemplatte oder Partition.

dd bs=1M conv=fdatasync if=./proxmox-backup-server_*.iso of=/dev/XYZ

Der Befehl endet ohne Schreibfehler. Proxmox weist ausdrücklich darauf hin, dass der gewählte Stick dabei vollständig überschrieben wird.

Boote davon und wähle die grafische Installation. Kontrolliere im Installer Zielplatten, Zeitzone, Hostname und statische IP-Adresse vor dem endgültigen Installieren. Der Installer löscht die gewählten Platten. Wähle bei ZFS keine Hardware-RAID-Schicht darunter; diese Kombination wird in der Dokumentation als nicht unterstützt und datenverlustgefährdet genannt.

Nach dem Reboot meldest Du Dich auf Port 8007 als root im Realm Linux PAM an. Prüfe dort Hostname, IP und Zeitzone. Hinterlege außerdem eine erreichbare Administratoradresse für Paket- und Aufgabenmeldungen.

4. Datastore anlegen

Ein Datastore ist das Verzeichnis, in dem PBS Backups ablegt. Unterstützt sind laut Dokumentation ext4, XFS und ZFS. FAT-Dateisysteme scheiden aus: Ihnen fehlen POSIX-Eigentümer und sie haben zu niedrige Verzeichnisgrenzen. Lege vor destruktiven Schritten mit der Datenträgerliste fest, welche Platte wirklich frei ist.

proxmox-backup-manager disk list

In der Ausgabe muss der gewünschte Datenträger als unbenutzt erkennbar sein. Nur dann darfst Du ihn initialisieren.

proxmox-backup-manager disk initialize sdX

Danach besitzt sdX eine neue GPT. Dieser Befehl ist destruktiv; verwende statt sdX nur den zuvor geprüften Gerätenamen.

Für einen einzelnen ext4-Datenträger erstellt dieser dokumentierte Befehl Dateisystem und Datastore in einem Schritt. Der Name pve-backups ist ein Beispiel und kann in Deinem Konzept anders heißen.

proxmox-backup-manager disk fs create pve-backups --disk sdX --filesystem ext4 --add-datastore true

Bei Erfolg entsteht der Datastore unter /mnt/datastore/pve-backups. Für Redundanz auf zwei Platten kannst Du stattdessen in der Oberfläche unter Administration → Storage/Disks → ZFS einen Mirror erzeugen. Prüfe anschließend die erkannte Konfiguration:

proxmox-backup-manager datastore list

Die Ausgabe enthält Namen und Pfad des neuen Datastores. Verwende für die Sicherung keinen beliebigen Netzwerkordner als Ersatz: PBS erwartet sein spezifisches Layout mit vielen Chunk-Verzeichnissen.

Teil 3 – PVE anbinden und Regeln festlegen

5. PBS in Proxmox VE einbinden

Füge den Server in Proxmox VE unter Datacenter → Storage → Add → Proxmox Backup Server hinzu. Trage Server, Benutzer, Passwort oder API-Token sowie den Datastore ein und bestätige den Zertifikats-Fingerprint bewusst. Danach wählst Du diesen Storage in einem Backup-Job für VMs und Container.

Lege den Zeitplan so, dass er zu Deiner Änderungsrate und zum Backup-Fenster passt. Für die Grundlagen des PVE-Backups ist der vorhandene Leitfaden K3s-Backups mit etcd-Snapshots keine PBS-Anleitung, zeigt aber denselben Grundsatz: Ein Backup ist erst mit dokumentierter Wiederherstellung belastbar.

Aufbewahrung: Prune ist nicht gleich Speicher freigeben

Definiere Retention anhand der benötigten Wiederherstellungspunkte statt anhand einer beliebigen Zahl. PBS kennt keep-last, stündliche, tägliche, wöchentliche, monatliche und jährliche Regeln. Die Regeln werden in dieser Reihenfolge verarbeitet; spätere Regeln betrachten nur noch ältere Sicherungen.

Prune entfernt nur Snapshot-Metadaten. Die eigentlichen, nicht mehr referenzierten Chunks werden erst durch Garbage Collection bereinigt. Deshalb kann freier Platz nach einem Prune ausbleiben. Proxmox empfiehlt für GC in den meisten Setups einen wöchentlichen Zeitplan.

proxmox-backup-manager datastore update pve-backups --gc-schedule 'Sun 03:30'

Der Datastore übernimmt damit einen wöchentlichen GC-Zeitpunkt. Plane ihn außerhalb des Backup-Fensters, damit Datenträger und Netzwerk nicht unnötig konkurrieren.

6. Integrität prüfen und zweite Kopie planen

Ein erfolgreich geschriebener Task beweist nicht, dass jedes gespeicherte Backup langfristig lesbar bleibt. Lege deshalb im Datastore einen Verify Job an. Die offizielle Dokumentation empfiehlt, alle Backups mindestens monatlich erneut zu verifizieren; für neue und abgelaufene Sicherungen ergänzen regelmäßige Jobs diese erneute Gesamtprüfung.

proxmox-backup-manager verify pve-backups --read-threads 1 --verify-threads 4 --ignore-verified false

Der Befehl startet eine vollständige Prüfung mit den in der Dokumentation gezeigten Threadwerten. Plane die regelmäßige Variante in der Weboberfläche unter Datastore → Verify Jobs, damit die Prüfung nicht von manueller Disziplin abhängt.

Für eine zweite Kopie richtest Du auf einem zweiten PBS zunächst unter Configuration → Remotes den Gegenserver mit Hostname, Benutzer und Zertifikats-Fingerprint ein. Der Fingerprint wird auf dem Remote-PBS angezeigt:

proxmox-backup-manager cert info | grep Fingerprint

Vergleiche den angezeigten SHA-256-Fingerprint über einen vertrauenswürdigen Weg. Erst dann lege den Remote an; so bindest Du nicht versehentlich einen falschen Server ein.

proxmox-backup-manager sync-job create offsite-pull --remote pbs2 --remote-store pve-backups --store pve-backups --schedule 'Wed 02:30'

Dieser dokumentierte Pull-Job holt einen Remote-Datastore in den lokalen Datastore. In einem produktiven Entwurf müssen Quell- und Zielnamen bewusst unterschiedlich geplant sein. Bei einem weniger vertrauenswürdigen Ziel kann verified-only sicherstellen, dass nur bereits geprüfte Snapshots synchronisiert werden.

7. Zugriff, Benachrichtigungen und Wiederherstellung vorbereiten

Ein Backup-System braucht getrennte Rollen. Nutze den Root-Zugang für Einrichtung und Wartung, aber vergib für automatisierte oder delegierte Aufgaben nur die notwendigen Datastore-Rechte. PBS kann Rechte auf Datastore- und Namespace-Ebene begrenzen. Das ist besonders nützlich, wenn mehrere PVE-Cluster, Mandanten oder Laborumgebungen denselben Server verwenden: Eine Quelle muss nicht automatisch alle Sicherungen sehen oder entfernen können.

Aktiviere Benachrichtigungen und prüfe ihre Zustellung anhand eines echten Aufgabenlaufs. PBS kann über geplante Verifikation, Garbage Collection und Synchronisation informieren. Eine Meldung ersetzt aber nicht die Kontrolle des Task-Logs: Sie soll dazu führen, dass Du fehlgeschlagene Jobs zeitnah untersuchst. Dokumentiere außerdem, welche Person Zugang zu PBS hat und wo die Zugangsdaten sowie gegebenenfalls Verschlüsselungsschlüssel liegen.

Die Wiederherstellung vor dem Notfall planen

Halte fest, welche Reihenfolge nach einem Totalausfall gilt: zuerst PBS erreichbar machen, dann den Datastore einbinden, anschließend PVE-Storage hinterlegen und erst danach kritische Maschinen wiederherstellen. Wenn ein Datastore aus einer vorherigen Instanz weiterverwendet wird, darf immer nur eine PBS-Instanz gleichzeitig darauf arbeiten. Die offizielle Speicher-Dokumentation nennt das ausdrücklich für S3-Backends; grundsätzlich schützt dieses Prinzip vor konkurrierenden Schreibvorgängen und unklaren Besitzverhältnissen.

Eine Restore-Probe sollte nicht nur den Assistenten bis zum Ende durchklicken. Stelle eine kleine Test-VM oder einen Container in ein isoliertes Netz wieder her, boote sie und prüfe den Dienst fachlich. Bei einer Datenbank bedeutet das beispielsweise Anmeldung und eine gezielte Abfrage; bei einer Webanwendung eine HTTP-Antwort und relevante Daten. Notiere Zeitpunkt, Snapshot, Dauer und Ergebnis. So erkennst Du später, ob Speicher, Netzwerk und Zugänge für die verlangte Wiederherstellungszeit ausreichen.

8. Offsite-Synchronisation sicher betreiben

Ein zweiter PBS ist kein magischer Schutz, wenn derselbe administrative Zugang beide Systeme kontrolliert. Richte auf dem Ziel deshalb einen dedizierten Benutzer oder API-Token ein und beschränke dessen Rechte auf den benötigten Datastore oder Namespace. Die Remote-Konfiguration benötigt Hostname oder IP-Adresse, Benutzer, Passwort und Zertifikats-Fingerprint. Der Fingerprint ist kein Detail: Er bindet die Verbindung an den erwarteten TLS-Endpunkt.

Für Pull-Jobs kopiert der lokale PBS Inhalte eines Remote-Datastores in einen lokalen Datastore. Du kannst Jobs regelmäßig planen oder zunächst manuell ausführen. Erst nach einem erfolgreichen Testlauf solltest Du Optionen wie remove-vanished erwägen, denn diese können nicht mehr vorhandene Snapshots und Gruppen am Ziel entfernen. Für ein weniger vertrauenswürdiges Ziel begrenzt verified-only den Transfer auf bereits geprüfte Snapshots; encrypted-only beschränkt ihn auf verschlüsselte Snapshots.

Bei Push-Jobs ist laut Proxmox für jeden Job eine eigene Remote-Konfiguration mit einem eigenen Benutzer ratsam. Andernfalls können Jobs, die dasselbe Ziel benutzen, sich bei aktivem remove-vanished gegenseitig Gruppen oder Snapshots beeinflussen. Begrenze außerdem die Bandbreite, wenn die Standortanbindung nebenbei produktive Dienste versorgt. Die Dokumentation zeigt hierfür --rate-in für Pull- und --rate-out für Push-Richtung.

proxmox-backup-manager sync-job update offsite-pull --rate-in 20MiB

Damit wird die eingehende Synchronisation des Jobs begrenzt. Prüfe danach im Task-Log, ob der Job startet, den erwarteten Quell- und Ziel-Datastore nennt und mit TASK OK endet. Ein Durchlauf ohne neue Daten kann ebenfalls korrekt sein; die offizielle Beispielausgabe meldet dann, dass keine neuen Daten zum Abruf gefunden wurden.

Die wichtigsten Stolperfallen

PBS läuft auf demselben Hypervisor

Symptom: Nach einem Ausfall des PVE-Hosts sind Backup-Oberfläche und Daten zugleich nicht erreichbar. Ursache: Compute und Sicherung teilen den Fehlerbereich. Lösung: PBS auf separater physischer Hardware betreiben und zusätzlich offsite synchronisieren.

Der falsche Datenträger wird initialisiert

Symptom: Ein bestehendes Dateisystem oder Daten sind verschwunden. Ursache: sdX wurde ohne Abgleich verwendet. Lösung: Vor jedem Initialisieren disk list und Größenmodell prüfen; destruktive Befehle niemals blind kopieren.

Nach Prune wird kein Speicher frei

Symptom: Snapshot-Anzahl sinkt, die Belegung aber nicht. Ursache: Prune entfernt nur Metadaten; Chunks bleiben bis zur Garbage Collection. Lösung: GC einplanen und die dokumentierte Schonfrist beachten.

Eine externe FAT-Platte wird als Datastore verwendet

Symptom: Der Datastore lässt sich nicht sauber erstellen oder betreiben. Ursache: FAT unterstützt erforderliche Eigentümer- und Verzeichniseigenschaften nicht. Lösung: Die Platte nach Datenprüfung mit ext4 oder XFS formatieren.

Offsite-Sync löscht unerwartet Daten

Symptom: Gruppen fehlen nach einer Synchronisation. Ursache: remove-vanished oder ein zu weit berechtigtes Konto wurde ohne Konzept verwendet. Lösung: Rechte und Richtung prüfen, je Push-Job einen dedizierten Remote-Benutzer verwenden und Löschoptionen erst nach einem Test aktivieren.

Verifikation: So prüfst du, dass alles läuft

Prüfe zuerst, ob PBS den Datastore kennt und der Pfad plausibel ist:

proxmox-backup-manager datastore list

Erwartet wird eine Tabelle mit pve-backups und seinem Pfad. Danach zeigt der Detailabruf Zeitpläne und Aufbewahrungswerte:

proxmox-backup-manager datastore show pve-backups

Erwartet werden Eigenschaften wie Name, Pfad und – sofern gesetzt – gc-schedule. Prüfe anschließend in Proxmox VE den letzten Backup-Task auf TASK OK und öffne im PBS-Datastore den Content-Tab: Die VM- oder CT-Gruppe muss dort mit einem Snapshot erscheinen.

Starte zuletzt eine kontrollierte Wiederherstellung einer unkritischen VM oder eines Containers in ein isoliertes Ziel. Prüfe Start, Netzwerk und die fachlich relevanten Daten. Ergänzend helfen die Beiträge zu Restic-Docker-Backups und Docker-Healthchecks, wenn auch Dienste außerhalb von PVE abgesichert und geprüft werden sollen.

Fazit

Proxmox Backup Server einrichten bedeutet mehr als einen Backup-Job anzuklicken. Ein separater Server, ein korrekt angelegter Datastore, definierte Retention, Garbage Collection und regelmäßige Verifikation machen aus Sicherungen einen belastbaren Wiederherstellungsweg. Eine zweite PBS-Instanz mit bewusst gesetzten Rechten ergänzt diesen Weg um einen getrennten Standort. Entscheidend bleibt die regelmäßige Restore-Probe.

Quellen

• Proxmox Backup Server – Installation
• Proxmox Backup Server – Backup Storage
• Proxmox Backup Server – Maintenance Tasks
• Proxmox Backup Server – Managing Remotes & Sync

Häufige Fragen