Proxmox Backup Server einrichten und testen

Ein Backup, das auf dem Rechner liegt, den es retten soll, ist der Ersatzschlüssel unter der Fußmatte des brennenden Hauses. Dieser Guide stellt Proxmox Backup Server auf ein eigenes Gerät und endet mit dem einzigen Test, der zählt: der Wiederherstellung.

Kurzantwort

Wie richtest du Proxmox Backup Server so ein, dass er dich im Ernstfall wirklich rettet? Installiere ihn per ISO auf einem eigenen Rechner, lege den Datastore auf eine eigene Platte, gib Proxmox VE ein Token, das sichern, aber nicht löschen darf, plane Prune-, Garbage-Collection- und Verify-Jobs, bewahre den Schlüssel (falls du einen nutzt) getrennt von beiden Rechnern auf und stelle eine Test-VM unter neuer ID wieder her. Stand 25. Okt. 2026 ist Version 4.2 aktuell, veröffentlicht am 29. Apr. 2026 [17][18]. Deduplizierung heißt: Jeder Datenblock wird nur einmal gespeichert, egal wie viele Snapshots auf ihn zeigen [4]. Wie viel Platz das spart, hängt komplett von deinen Daten ab, deshalb nennen wir keine Zahl als Versprechen.

So funktioniert’s

1. Ein eigenes Gerät. Die Proxmox-Dokumentation rät davon ab, den Backup-Server direkt auf dem Hypervisor zu installieren: Ein separater physischer Server hält die Backups erreichbar, wenn der Hypervisor ausfällt [2]. Auch das Proxmox-VE-Handbuch empfiehlt einen dedizierten Host für Proxmox Backup Server [14], und ein FAQ eines Proxmox-Mitarbeiters nennt VM, LXC-Container oder Betrieb neben Proxmox VE möglich, aber nur für Experten [20]. Unsere Einschätzung: Eine PBS-VM auf dem Host, den sie sichert, taugt für einen Wegwerf-Test und ist als einzige Kopie falsch. Fällt der Host aus, sind die Backups mit weg. Schon ein kleiner zweiter Rechner löst das.
2. Was das Gerät braucht. Für den Produktivbetrieb empfiehlt die Dokumentation eine moderne 64-Bit-CPU mit mindestens 4 Kernen, mindestens 4 GiB RAM für das System plus 1 GiB je TiB Backup-Speicher, 32 GiB oder mehr für die Systemplatte und redundante Netzwerkkarten mit mehreren Gigabit [2]. Für die Backup-Platte bevorzugt sie schnellen lokalen Speicher mit hohen IOPS bei zufälligem Zugriff, am besten Enterprise-SSDs, und bei Festplatten einen Metadaten-Cache wie ein ZFS Special Device im Spiegel [2]. Das Minimum zum Ausprobieren (2 Kerne, 2 GB RAM, mehr als 8 GB Platte) ist ausdrücklich nicht für die Produktion gedacht [2]. Preise nennen wir nicht; prüfe sie am Kauftag.
3. Ein NAS als Datastore? Die Dokumentation verlangt schnellen lokalen Speicher und nennt NFS oder SMB in der gelesenen Anforderungsliste nicht [2]. In einer Diskussion auf der Proxmox-Entwicklerliste von 2024 schlug ein Entwickler eine Warnung vor NFS und SMB vor; ein anderer Proxmox-Mitarbeiter widersprach einer pauschalen Empfehlung und regte einen kleinen schnellen lokalen Datastore an, der auf einen größeren, langsameren Remote-Speicher synchronisiert wird [22]. Selbst gemessen haben wir das nicht. Unsere Einschätzung: Ein Datastore auf einer Netzwerkfreigabe ist ein Kompromiss, den du vor dem Vertrauen messen solltest; die lokale Platte ist der sichere Standard.
4. Per ISO installieren. Lade das Installationsabbild bei proxmox.com herunter. Release 4.2-1 ist 1,48 GB groß und datiert auf den 29. Apr. 2026 [18]. Kopiere es mit dd bs=1M conv=fdatasync if=./proxmox-backup-server_*.iso of=/dev/XYZ (prüfe den Gerätenamen doppelt, der Stick wird gelöscht), mit Etcher oder mit Rufus im DD-Modus auf einen USB-Stick mit mindestens 2 GB; UNetbootin funktioniert nicht [2]. Der Installer fragt die Zielplatte (alles darauf wird gelöscht), das Dateisystem (standardmäßig ext4 mit LVM; XFS und ZFS sind Optionen), deinen Standort, ein Root-Passwort mit mindestens 8 Zeichen (die Dokumentation rät zu 12 oder mehr) samt E-Mail-Adresse und die Netzwerkeinstellungen ab [2]. ZFS auf einem Hardware-RAID-Controller wird nicht unterstützt und kann Daten kosten [2]. Bei der Installation kannst du entweder eine IPv4- oder eine IPv6-Adresse eintragen, nicht beide; die zweite ergänzt du später [2].
5. Erster Login und Updates. Öffne https://<Adresse>:8007, melde dich als root im Realm Linux PAM an und prüfe IP-Konfiguration, Hostnamen und Zeitzone [2]. Die Zeitzone zählt: Alle Zeitpläne richten sich nach der Zeitzone des Servers [10]. Das Enterprise-Repository ist standardmäßig aktiv und braucht ein Abo; ohne Abo wechselst du auf das No-Subscription-Repository, das die Dokumentation für Tests und Nicht-Produktion nennt und für Produktivserver nicht empfiehlt [2]. Laut Pressemitteilung vom 29. Apr. 2026 beginnen Abos bei 560 Euro pro Server und Jahr, mit unbegrenztem Speicher und unbegrenzt vielen Clients; aktuelle Konditionen stehen bei proxmox.com [17]. Updates laufen mit apt update und apt full-upgrade; das FAQ warnt, dass ein einfaches apt upgrade ein Rolling-Release-System halb aktualisiert zurücklassen kann [7]. Die Support-Tabelle im FAQ führt Proxmox Backup 4 (Debian 13) ohne angekündigtes Ende und Proxmox Backup 3 mit Support-Ende im August 2026 [7]. Dieses Datum ist bereits verstrichen. Beides gilt mit Stand 25. Okt. 2026.
6. Der Datastore. Ein Datastore ist ein Verzeichnis auf einem normalen Linux-Dateisystem: ext4, XFS oder ZFS [1]. Das Dateisystem muss mindestens 65.538 Unterverzeichnisse pro Verzeichnis zulassen, weil PBS 65.536 Chunk-Verzeichnisse vorab anlegt; FAT wird nicht unterstützt [1]. Das Beispiel der Dokumentation legt auf einer freien Platte Dateisystem und Datastore in einem Schritt an [1]. Nimm die Datenplatte getrennt von der Systemplatte.
7. Deduplizierung, einfach erklärt. PBS zerlegt Backup-Daten in Chunks und benennt jeden Chunk nach seiner SHA-256-Prüfsumme; gleicher Inhalt bekommt denselben Namen und wird einmal gespeichert [4]. Virtuelle Platten werden in Chunks fester Größe zerlegt, typischerweise 4 MiB; Datei-Backups nutzen Chunks dynamischer Größe, die ein Rolling Hash findet, sodass eine geänderte Datei nicht jeden folgenden Chunk verschiebt [4]. Ein Client lädt nur Chunks hoch, die der Server noch nicht hat, doch jeder Snapshot verweist auf alle Chunks und gilt als vollständiges Backup [4][7]. Proxmox VE kann geänderte Blöcke einer laufenden VM zusätzlich mit Dirty Bitmaps verfolgen [4]. Die Daten werden mit Zstandard komprimiert [8]. Für eine Größenordnung: Das Garbage-Collection-Beispiel der Dokumentation nennt 327.160.886.391 Byte Originaldaten und 52.767.414.743 Byte auf der Platte (16 %) [5]. Das ist ein Beispiel aus dem Handbuch, keine Prognose. Die Ausgabe der Garbage Collection im Handbuch endet genau mit diesen Zeilen, dein eigenes Verhältnis sollte also im Aufgabenprotokoll deiner Garbage Collection stehen; auf eigener Hardware haben wir das nicht geprüft. Zwei Einschränkungen: Mit verschiedenen Schlüsseln verschlüsselte Chunks deduplizieren nicht gegeneinander, deshalb rät Proxmox zu getrennten Datastores je Schlüssel [13], und verschlüsselte Backups bilden den Hash aus Klartext und Schlüssel [4].
8. Ein Benutzer und ein Token, die nicht löschen können. Lege einen Benutzer im PBS-Realm an, etwa backup@pbs, in der Weboberfläche (Configuration, Access Control, User Management) oder mit proxmox-backup-manager user create [6]. Erzeuge dann je Proxmox-VE-Host oder -Cluster ein API-Token; sein Secret wird nur einmal angezeigt [6]. Neue Tokens haben keine Rechte; du vergibst die Rolle DatastoreBackup, die eigene Backups sichern und wiederherstellen darf, auf dem engen Pfad eines Datastores oder Namespaces [6]. Ein Token kann nie mehr als sein Benutzer, also braucht auch der Benutzer die Berechtigung [6]. Genau dieses Muster empfiehlt die Dokumentation gegen Ransomware: getrennte Tokens je Host, minimale Rechte, keine Löschberechtigung, und das Aufräumen übernehmen Prune-Jobs auf dem Backup-Server selbst [1].
9. Proxmox VE anbinden. Füge den Server unter Datacenter, Storage hinzu oder mit pvesm add pbs [12]. Du brauchst Serveradresse, Datastore, Benutzername, Passwort und bei selbstsigniertem Zertifikat den Fingerabdruck aus proxmox-backup-manager cert info [12][13]. Die PBS-Dokumentation beschreibt ein API-Token als Kennung der Form user@realm!tokenname plus Secret, die ein Client anstelle von Benutzer-ID und Passwort bekommt [6]. Die Proxmox-VE-Storage-Seite zeigt in ihren Beispielen nur normale Benutzer, deshalb konnten wir die Token-Form dort aus den Handbüchern allein nicht bestätigen; teste sie, bevor du dich darauf verlässt. Die Backup-Jobs laufen danach in den gewohnten Proxmox-VE-Dialogen. Der Snapshot-Modus hat die geringste Ausfallzeit bei kleinem Konsistenzrisiko, und der Gast-Agent hilft beim Einfrieren des Dateisystems [14].
10. Prune: entscheiden, was bleibt. Prune entfernt Snapshots nach einer Aufbewahrungsregel: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. Sie werden in dieser Reihenfolge angewendet, und jede Option betrachtet nur Snapshots, die älter sind als die schon behaltenen; Wochen laufen von Montag bis Sonntag [3]. Probiere Werte im eingebauten Prune-Simulator aus, bevor du sie festlegst [3]. Das Langzeitbeispiel der Dokumentation behält 3 letzte, 13 tägliche, 8 wöchentliche, 11 monatliche und 9 jährliche Snapshots und rät zu großzügiger Aufbewahrung, weil du sie später kürzen, alte Snapshots aber nicht neu erzeugen kannst [3]. Prune löscht nur Metadaten; die Daten-Chunks bleiben bis zur Garbage Collection [3]. Sensible Daten in alten Chunks überleben das Prune deshalb bis zur nächsten Garbage Collection [3].
11. Garbage Collection: Platz freigeben. Die Garbage Collection läuft je Datastore in zwei Phasen. Phase eins markiert jeden Chunk, auf den ein Index zeigt, indem sie seine Zugriffszeit aktualisiert; Phase zwei räumt Chunks weg, die seit einem Stichtag nicht berührt wurden, nämlich dem ältesten laufenden Backup oder 24 Stunden und 5 Minuten vor dem Start [3]. Chunks innerhalb dieser Schonfrist erscheinen als ausstehende Entfernungen, deshalb kommt der Platz nicht sofort zurück [3]. Die Dokumentation empfiehlt einen Zeitplan und nennt einen wöchentlichen Lauf als guten Anfang [3]. Zeitpläne nutzen ein Kalenderformat nach Art von systemd, etwa sat 04:30 oder mon..fri 02:00 [10].
12. Verify: zurücklesen. Ein Verify-Job liest Chunks und vergleicht sie mit den SHA-256-Prüfsummen im Manifest jedes Snapshots [3][7]. Die Dokumentation empfiehlt, alles mindestens monatlich neu zu verifizieren, weil Laufwerke leise altern, und schlägt einen häufigen Job für neue und veraltete Snapshots plus einen selteneren für alles vor [3]. Bei verschlüsselten Chunks kennt der Server nur die Prüfsumme des Klartexts und kann sie ohne Schlüssel nicht nachrechnen, deshalb prüft er nur die CRC-32 [4]. Ein bestandener Verify sagt: Die Daten auf der Platte sind intakt. Er sagt nicht, dass du ein lauffähiges System zurückbekommst; dafür ist Schritt 14 da.
13. Schlüssel und Geheimnisse. Die clientseitige Verschlüsselung nutzt AES-256 im GCM-Modus und ist standardmäßig aus [5][7]. Proxmox rät für einen Server im vertrauenswürdigen lokalen Netz selbst zum Verzicht, weil unverschlüsselte Backups sich leichter wiederherstellen lassen [13]. Verschlüssele, wenn das Ziel weniger vertrauenswürdig ist, etwa bei einer Offsite-Kopie. Ohne Schlüssel lässt sich ein verschlüsseltes Backup nicht lesen, und ein Schlüssel, der nur auf dem zu rettenden Rechner liegt, ist mit ihm verloren [5]. Die Dokumentation empfiehlt Passwortmanager, USB-Stick an einem sicheren Ort und eine Papierkopie mit dem Unterbefehl paperkey [5][13]. Der Proxmox-VE-Storage akzeptiert nur Schlüssel ohne Passwort (--kdf none) [13]. Ein Master-Schlüsselpaar legt eine RSA-verschlüsselte Kopie des Schlüssels neben jedes Backup [5]. Seit 4.2 können Push-Sync-Jobs Snapshots außerdem auf dem Weg zu einem weniger vertrauenswürdigen Ziel verschlüsseln [17][19].
14. Der Wiederherstellungstest. Öffne in Proxmox VE den Storage, wähle ein Backup, klicke auf Restore und vergib eine neue VM-ID, damit das Original nicht überschrieben wird [21]. Auf der Kommandozeile listest du die Backups mit pvesm list <Storage> --content backup und stellst mit qmrestore <Volume-ID> <neue-VMID> wieder her [15][16][21]. Die Option --unique vergibt eine neue zufällige MAC-Adresse [15]; --start ist standardmäßig aus [15]. Die Schaltfläche File Restore öffnet einen Dateibrowser in einem PBS-Backup einer VM oder eines Containers [14]. Bei großen VMs startet die Live-Wiederherstellung die VM sofort und kopiert die Daten im Hintergrund, mit langsameren Lesezugriffen in der Zwischenzeit und einem undefinierten Zustand, falls sie scheitert [14][15]. Ist der Server selbst weg, kann proxmox-backup-debug recover index aus Index- und Chunk-Dateien ein Abbild rekonstruieren, bei verschlüsselten Backups mit der Schlüsseldatei [4]. Die Dokumentation sagt es ausdrücklich: regelmäßig Wiederherstellungstests durchführen [5].
15. Zweite Kopie, außer Haus. Ein PBS ist eine Kopie. Ein Remote und ein Sync-Job ziehen einen Datastore von einem anderen PBS; dafür brauchst du Host, Benutzer und den Zertifikat-Fingerabdruck [9]. Die Option remove-vanished löscht lokal Snapshots, die an der Quelle verschwunden sind. Proxmox weist darauf hin, dass sie ausgeschaltet verhindert, dass ein Angreifer, der die Quelle übernommen hat, deine Offsite-Kopien löscht [1][9]. Seit 4.2 sind S3-kompatible Objektspeicher offiziell als Datastore-Backend unterstützt; die Dokumentation warnt, dass Anbieter Speicher, Anfragen und Traffic berechnen können [1][17]. Unser Guide zum Offsite-Backup fürs Homelab behandelt die dritte Kopie.

Ein Homelab-Beispiel

Das ist ein Beispiel, kein Bericht über unsere Systeme. Wir machen keine Aussage dazu, welche Backup-Software Bytearium nutzt oder wie es um die Backups steht. Angenommen: ein Proxmox-VE-Host pve1 und ein zweiter Rechner pbs1 mit System-SSD und Datenplatte sdb. Die Adressen sind Platzhalter.

Auf pbs1 ergänzt du ohne Abo das No-Subscription-Repository in /etc/apt/sources.list.d/proxmox.sources und setzt im Block von /etc/apt/sources.list.d/pbs-enterprise.sources die Zeile Enabled: false [2]:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Führe apt update und apt full-upgrade aus und lege dann den Datastore an:

proxmox-backup-manager disk list
proxmox-backup-manager disk initialize sdb
proxmox-backup-manager disk fs create store1 --disk sdb --filesystem ext4 --add-datastore true

Das erzeugt den Datastore unter /mnt/datastore/store1 [1]. Jetzt Benutzer, Token und Berechtigungen, für Benutzer und Token gleichermaßen [6]:

proxmox-backup-manager user create backup@pbs
proxmox-backup-manager user generate-token backup@pbs pve1
proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id 'backup@pbs'
proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id 'backup@pbs!pve1'

Speichere das Token-Secret im Passwortmanager. Dann die Jobs. Angenommen, der Backup-Job in Proxmox VE läuft um 01:00; Prune um 02:30, Verify um 03:30 und die Garbage Collection samstags um 04:30 halten die Platte jeweils nur mit einer Aufgabe beschäftigt. Die Keep-Werte sind Beispielwerte; wähle sie danach, wie lange eine beschädigte Datei unbemerkt bleiben könnte [3][10][11]:

proxmox-backup-manager prune-job create nightly --store store1 --schedule '02:30' --keep-last 3 --keep-daily 7 --keep-weekly 4 --keep-monthly 6
proxmox-backup-manager verify-job create verify-all --store store1 --schedule '03:30' --ignore-verified true --outdated-after 30
proxmox-backup-manager datastore update store1 --gc-schedule 'sat 04:30'

Der Verify-Job mit --ignore-verified true und --outdated-after 30 prüft jede Nacht neue Snapshots und prüft ältere erneut, sobald ihre letzte Verifikation 30 Tage zurückliegt [11]. Hole den Fingerabdruck und verbinde dann pve1:

proxmox-backup-manager cert info | grep Fingerprint
pvesm add pbs pbs1 --server 192.0.2.20 --datastore store1 --username 'backup@pbs!pve1' --password --fingerprint AA:BB:CC:...

Ohne Wert lässt --password den Befehl nach dem Passwort fragen [12]. Nach der ersten Nacht machst du den Wiederherstellungstest mit einer unwichtigen VM. Liste die Backups auf und stelle sie unter neuer ID, mit neuer MAC-Adresse und ohne Start wieder her:

pvesm list pbs1 --content backup
qmrestore pbs1:backup/vm/100/2026-10-26T00:00:07Z 901 --unique

Die Volume-ID ist die, die pvesm list ausgibt; das Datum hier ist erfunden [16][21]. Trenne vor dem ersten Start das Netzwerk der wiederhergestellten VM oder ändere ihre IP-Adresse, damit nicht zwei Kopien derselben Maschine um eine Adresse streiten. Dieser Schritt ist unser Rat, nicht aus dem Handbuch. Prüfe dann, worauf es ankommt: Sie bootet, der Dienst startet, die Datenbank öffnet sich, eine bekannte Datei hat den erwarteten Inhalt. Notiere Datum und Ergebnis. Prüfe zuletzt nach dem ersten Samstag den Stand mit proxmox-backup-manager garbage-collection status store1 und lies im Aufgabenprotokoll des beendeten Laufs die Zeilen, die Originaldaten und Platzverbrauch vergleichen, wie im Beispiel des Handbuchs [5][11].

Prüfliste

• Installiere Proxmox Backup Server auf einem Rechner, der nicht der gesicherte Host ist, und halte die Datenplatte getrennt von der Systemplatte.
• Prüfe die Hardware gegen die Dokumentation: 4 Kerne, 4 GiB RAM plus 1 GiB je TiB und SSDs oder ein ZFS Special Device bei Festplatten.
• Wähle das No-Subscription-Repository nur für Tests und den Heimgebrauch und nutze apt full-upgrade statt apt upgrade.
• Kontrolliere die Zeitzone des Servers, bevor du Zeitpläne setzt.
• Erstelle je Proxmox-VE-Host ein Token mit der Rolle DatastoreBackup auf einem engen Pfad und gib dem zugehörigen Benutzer dieselbe Berechtigung.
• Speichere das Token-Secret im Passwortmanager, sobald es erscheint, denn es lässt sich nicht erneut anzeigen.
• Teste die Aufbewahrungsregel im Prune-Simulator und plane Prune-Jobs auf dem Backup-Server, nicht auf den Clients.
• Plane die Garbage Collection wöchentlich und rechne damit, dass der Platz nach der Schonfrist zurückkommt, nicht sofort.
• Plane einen Verify-Job, der Snapshots mindestens monatlich erneut prüft, und denke daran, dass er den Wiederherstellungstest nicht ersetzt.
• Entscheide dich bewusst für oder gegen Verschlüsselung: im vertrauenswürdigen LAN verzichten, für Offsite-Ziele nutzen, und den Schlüssel an drei Orten abseits beider Rechner ablegen.
• Stelle jedes Quartal eine unkritische VM unter neuer ID und ohne Netzwerk wieder her und notiere Datum und Ergebnis.
• Ergänze einen zweiten PBS oder ein Offsite-Ziel und lasse remove-vanished aus, solange du nicht willst, dass Löschungen mitwandern.

Passt dazu: Proxmox oder ESXi im Homelab; 3-2-1-Backup und Wiederherstellungstest; Offsite-Backup fürs Homelab: die dritte Kopie; ZFS: Mirror oder RAID-Z? Den Pool planen; Homelab-Backup mit restic oder Borg; Deduplizierung (Backups); GFS-Aufbewahrung (Backup); LXC-Container (Proxmox). Unsere Einschätzung: Ein ZFS-Mirror für die Datenplatte passt gut, wenn du deinen Pool ohnehin sorgfältig planst; der ZFS-Guide behandelt die Abwägungen.