PBS Sync-Jobs: Offsite-Backup auf zweiten Proxmox Backup Server

Wer Proxmox VE produktiv betreibt, kennt das Mantra: Ein Backup ist kein Backup. Erst wenn die Sicherung an einem zweiten, physisch getrennten Standort liegt, ist sie etwas wert. Genau dafür hat Proxmox in den Proxmox Backup Server (PBS) die sogenannten Sync-Jobs eingebaut — ein PBS-natives Replikationsverfahren von Datastore zu Datastore zwischen zwei PBS-Instanzen.

In diesem Beitrag zeigen wir Ihnen, wie Sie einen Sync-Job zwischen einem PBS in Ihrem Hauptstandort und einem zweiten PBS in einem Rechenzentrum, der Filiale oder bei einem Geschäftsführer im Heimnetz einrichten. Wir gehen auf API-Token, Verschlüsselung, Bandbreitenlimit und Group-Filter ein — und erklären, warum diese Variante einem klassischen rsync-Ansatz deutlich überlegen ist.

Warum PBS-Sync statt rsync?

Es liegt nahe, einen PBS-Datastore einfach per rsync auf ein zweites Storage zu kippen. Technisch funktioniert das — aber Sie verlieren dabei genau die Eigenschaften, die PBS überhaupt erst attraktiv machen:

Eigenschaft	rsync auf Datastore-Verzeichnis	PBS Sync-Job
Deduplizierung beim Transfer	nein, Chunks werden roh kopiert	ja, nur fehlende Chunks
Inkrementell auf Chunk-Ebene	nein, dateibasiert	ja, content-addressed
Signaturprüfung der Chunks	nein	ja, SHA-256 verifiziert
Verschlüsselung-Pass-through	nur Datei-Ebene	ja, Client-Encryption bleibt erhalten
Retention-Steuerung am Ziel	manuell	per Prune-Job pro Namespace
Konsistenz bei laufendem Backup	riskant	ja, Snapshots werden atomar transferiert
Resume nach Abbruch	begrenzt	ja, Chunk-genau

Hinzu kommt: PBS speichert keine VM-Disks als monolithische Dateien, sondern als Sammlung von 4-MiB-Chunks unter /.chunks/. Ein rsync über mehrere Millionen Kleinstdateien ist nicht nur langsam, sondern belastet auch das Metadaten-Subsystem des Quell-Dateisystems erheblich. Sync-Jobs lesen den Datastore über die PBS-API und übertragen nur die Chunks, die auf dem Ziel-Datastore tatsächlich fehlen.

Voraussetzungen und Architektur

Für ein sauberes Offsite-Setup brauchen Sie:

• Zwei PBS-Instanzen, mindestens Version 3.4 (Stand 2026). Empfohlen ist PBS 4.x mit dem aktuellen Sync-Job-Push/Pull-Modell.
• Erreichbarkeit auf TCP 8007 vom Quell- zum Ziel-PBS (oder umgekehrt im Push-Modus).
• Einen dedizierten Datastore am Ziel, idealerweise auf einem ZFS-Pool mit aktivierter Compression.
• Ausreichend Bandbreite — als Faustregel: das tägliche Backup-Delta sollte in 6-8 Stunden übertragbar sein.
• Optional: ein VPN oder eine direkte WireGuard-Verbindung, falls Sie den PBS nicht direkt ans Internet hängen wollen.

Architektonisch empfehlen wir den Pull-Modus: Der Ziel-PBS zieht aktiv vom Quell-PBS. So muss am Hauptstandort nur ein einziger ausgehender Port offen sein, und der Ziel-PBS am Offsite-Standort ist von außen nicht erreichbar.

API-Token am Quell-PBS anlegen

Sync-Jobs authentifizieren sich nicht mit Benutzer/Passwort, sondern mit einem API-Token. Das hat den Vorteil, dass Sie das Token jederzeit revoken können, ohne den eigentlichen Benutzer anzufassen.

Am Quell-PBS legen Sie unter Configuration — Access Control — API Token einen neuen Token an. Auf der Kommandozeile geht das ebenfalls schnell:

# Eigenen Sync-Benutzer anlegen
proxmox-backup-manager user create sync@pbs --comment "Offsite Sync"

# Token erstellen -- der Secret wird nur einmal angezeigt!
proxmox-backup-manager user generate-token sync@pbs offsite \
    --comment "Pull from offsite PBS"

# Berechtigung: nur lesend auf den Quell-Datastore
proxmox-backup-manager acl update /datastore/main \
    DatastoreReader \
    --auth-id 'sync@pbs!offsite'

Wichtig: Die Rolle DatastoreReader reicht für Pull-Sync vollkommen aus. Sie müssen dem Token keine Admin-Rechte geben. Notieren Sie sich Token-ID (sync@pbs!offsite) und Secret — das Secret wird verschlüsselt im Remote-Eintrag des Ziel-PBS hinterlegt.

Remote-Eintrag am Ziel-PBS

Am Ziel-PBS legen Sie nun unter Configuration — Remotes den Quell-PBS an. Vergeben Sie einen sprechenden Namen, etwa pbs-hq. Tragen Sie Hostname/IP, Port (Standard 8007), die Token-ID und das Token-Secret ein. Den Fingerprint des Server-Zertifikats finden Sie am Quell-PBS via proxmox-backup-manager cert info.

Auf der CLI:

proxmox-backup-manager remote create pbs-hq \
    --host pbs.hq.example.com \
    --auth-id 'sync@pbs!offsite' \
    --password 'TOKEN-SECRET' \
    --fingerprint 'aa:bb:cc:...'

Mit proxmox-backup-manager remote list prüfen Sie, ob der Eintrag steht. Ein proxmox-backup-manager remote test pbs-hq zeigt, ob die Verbindung und das Token funktionieren.

Sync-Job konfigurieren — Schedule, Bandbreite, Group-Filter

Der eigentliche Sync-Job verknüpft Remote, Quell-Datastore und Ziel-Datastore. Ein realistisches Beispiel für ein KMU mit drei Backup-Gruppen (vm/ct/host):

proxmox-backup-manager sync-job create offsite-nightly \
    --remote pbs-hq \
    --remote-store main \
    --store offsite \
    --schedule 'mon..fri 02:30' \
    --rate-in 50MiB \
    --group-filter 'type:vm' \
    --group-filter 'type:ct' \
    --remove-vanished false \
    --comment 'Nightly pull from HQ'

Die wichtigsten Optionen im Überblick:

• --schedule nimmt das systemd-Calendar-Format. mon..fri 02:30 läuft werktags um 02:30 Uhr.
• --rate-in setzt das Bandbreitenlimit beim Pull — hier 50 MiB/s, also rund 400 Mbit/s. Damit bleibt die WAN-Leitung tagsüber frei.
• --group-filter schränkt ein, was synchronisiert wird. type:vm und type:ct schließen Host-Backups aus, die offsite oft uninteressant sind.
• --remove-vanished false lässt am Ziel Snapshots stehen, die an der Quelle bereits gepruned wurden. So bauen Sie offsite eine längere Aufbewahrung als am Hauptstandort — klassisch 30 Tage HQ, 90 Tage Offsite.

Verschlüsselung-Pass-through und Retention am Ziel

Ein häufiges Missverständnis: Wenn die VM-Backups am Quell-PBS bereits client-verschlüsselt sind (--keyfile am PVE), bleiben sie es auch am Ziel. PBS überträgt die Chunks unverändert. Der Ziel-PBS sieht ebenfalls nur verschlüsselte Chunks — er hat keinen Zugriff auf den Klartext. Das ist genau das, was Sie für ein DSGVO-konformes Offsite-Backup wollen, etwa wenn der zweite PBS bei einem externen Dienstleister steht.

Den Schlüssel müssen Sie natürlich getrennt sichern — ohne ihn ist das Offsite-Backup im Ernstfall wertlos. Ein versiegelter Umschlag im Bankschließfach ist die unromantische, aber funktionierende Lösung.

Für die Retention am Ziel-PBS legen Sie pro Datastore einen Prune-Job an, der unabhängig vom Sync läuft:

proxmox-backup-manager prune-job create offsite-prune \
    --store offsite \
    --schedule 'sun 04:00' \
    --keep-daily 14 \
    --keep-weekly 8 \
    --keep-monthly 12

So entkoppeln Sie die Aufbewahrungsstrategien beider Standorte sauber voneinander — ein Kernvorteil gegenüber rsync-Lösungen, bei denen man am Ziel mühsam Spiegelbilder pflegt. Mehr zu sauberen Backup-Konzepten finden Sie in unserem Backup-Service.

Monitoring und Praxis-Tipps

Ein Sync-Job, der niemand überwacht, ist Schrödingers Backup. Drei Dinge sollten Sie verdrahten:

1. E-Mail-Benachrichtigung in /etc/proxmox-backup/node.cfg aktivieren, mindestens auf notify-error. Sie wollen wissen, wenn drei Nächte am Stück nichts gelaufen ist.
2. Verification-Job am Ziel-PBS, der wöchentlich die Chunks gegen ihre SHA-256 prüft. Bit-Rot auf dem Offsite-Storage merkt man sonst erst im Restore.
3. Restore-Test mindestens quartalsweise: Eine kleine Test-VM vom Offsite-PBS zurückspielen und booten. Nur so wissen Sie, dass die gesamte Kette — Schlüssel, Netz, Datastore, PVE — tatsächlich funktioniert.

In der Praxis sehen wir bei Kunden initiale Syncs von mehreren Terabyte über VDSL-Leitungen mit 50 Mbit/s Upload. Ein solcher Erstsync läuft mehrere Tage, aber dank Chunk-Resume übersteht er auch Verbindungsabbrüche. Wer schneller will: Den Ziel-PBS einmalig im Hauptstandort einsynchronisieren und dann physisch an den Offsite-Standort bringen — ein klassisches “Sneaker-Net” für das initiale Seeding.

Fazit

Mit PBS Sync-Jobs bekommen Sie ein robustes, dedupliziertes, kryptografisch signiertes Offsite-Backup, das mit klassischen rsync-Bastellösungen nicht mithalten kann. API-Token, Group-Filter und unabhängige Prune-Jobs am Ziel machen das Setup auch für SMB-Umgebungen handhabbar — und im Disaster-Recovery-Fall haben Sie eine zweite, vollwertige Backup-Instanz, von der Sie direkt restoren können.

DATAZONE unterstützt Sie bei der Konzeption und Umsetzung Ihrer Backup-Strategie — von der Auslegung der PBS-Hardware über die Einrichtung der Sync-Jobs bis hin zum Disaster-Recovery-Test. Sprechen Sie uns an unter Kontakt oder informieren Sie sich zu unserer Proxmox-Beratung und unseren Backup-Lösungen.