Proxmox Backup Server 4.2: S3-Offsite-Backups einrichten und gegen Löschen absichern

Seit Proxmox Backup Server (PBS) 4.2 sind S3-kompatible Objektspeicher als Speicher-Backend für Datastores offiziell unterstützt und keine Technologievorschau mehr. Damit lässt sich eine Offsite-Kopie Ihrer Backups direkt in einen Bucket bei einem externen Anbieter oder in einen eigenen Objektspeicher legen. Diese Anleitung zeigt die Einrichtung nach der offiziellen PBS-Dokumentation und erklärt, wie weit sich die Kopie gegen Löschen absichern lässt. Grundlage ist PBS 4.2.8 (Stand Oktober 2026).

Voraussetzungen

• Proxmox Backup Server 4.2 mit mindestens einem bestehenden lokalen Datastore. Proxmox empfiehlt für den Server mindestens 4 CPU-Kerne, 4 GiB RAM plus 1 GiB je TiB Backup-Speicher und 32 GiB Systemspeicher.
• Ein eigenes Laufwerk, eine Partition oder ein ZFS-Dataset mit Quota von 64 bis 128 GiB als lokaler Cache, möglichst auf SSD. Ein bestehender Datastore kann nicht als Cache dienen.
• Ein S3-kompatibler Objektspeicher mit HTTPS-Zugang, ein leerer Bucket und ein Zugangsschlüssel mit den Rechten Get, Put, List und Delete auf diesen Bucket
• Ausreichende Bandbreite für den ersten Abgleich; die Folgeläufe übertragen nur neue Chunks
• Root-Zugang zur PBS-Shell oder ein Administrator-Konto in der Weboberfläche

Schritt 1: Bucket und Zugangsschlüssel beim Anbieter vorbereiten

PBS legt weder Buckets an noch verwaltet es Zugriffsrechte beim Anbieter. Erstellen Sie den Bucket deshalb vorab in der Oberfläche Ihres Anbieters und einen Zugangsschlüssel, der nur für diesen Bucket gilt. PBS braucht laut Dokumentation die Rechte, Objekte zu lesen, zu schreiben, aufzulisten und zu löschen.

Aktivieren Sie für diesen Bucket kein Object Lock und keine Aufbewahrungsregeln des Anbieters, die Löschvorgänge blockieren. Die Garbage Collection von PBS entfernt nicht mehr benötigte Chunks per DELETE; scheitert das, wächst der Bucket unkontrolliert. Unveränderliche Backups auf S3 sind im Proxmox-Bugtracker als Bug 6780 beantragt und dort am 14.10.2026 noch offen.

Notieren Sie Endpunkt-Adresse, Region, Bucket-Namen, Access Key und Secret Key. Prüfen Sie in der Anbieterdokumentation, ob der Endpunkt Path-Style-Adressierung verlangt (Bucket im Pfad statt im Hostnamen). Bei selbst betriebenem Objektspeicher mit selbst signiertem Zertifikat brauchen Sie zusätzlich dessen SHA-256-Fingerabdruck, denn PBS spricht S3 ausschließlich über HTTPS.

Verifizieren: In der Anbieteroberfläche ist der Bucket leer, Versionierung und Object Lock sind aus, und der Schlüssel ist ausschließlich diesem Bucket zugeordnet.

Schritt 2: S3-Endpoint in PBS anlegen und prüfen

Den Endpoint legen Sie in der Weboberfläche unter Konfiguration > Remotes > S3 Endpoints an oder auf der Shell. In der Endpunkt-Adresse können Sie die Platzhalter {{bucket}} und {{region}} verwenden; der Bucket selbst gehört zur Datastore-Konfiguration, damit sich ein Endpoint für mehrere Buckets nutzen lässt.

proxmox-backup-manager s3 endpoint create offsite-s3 \
  --access-key 'ACCESS-KEY' \
  --secret-key 'SECRET-KEY' \
  --endpoint '{{bucket}}.s3.{{region}}.ANBIETER.example' \
  --region REGION

Verlangt der Anbieter Path-Style, ergänzen Sie --path-style true, bei eigenem Port --port und bei selbst signiertem Zertifikat --fingerprint. Bietet der Anbieter keine Sammel-Löschung an, setzen Sie --provider-quirks delete-objects-via-delete-object; diese Option ist mit PBS 4.2 hinzugekommen. Mit --rate-in, --rate-out und --limit-active-requests begrenzen Sie Bandbreite und Schreibanfragen. Weil der Secret Key auf der Shell im Verlauf landet, ist die Weboberfläche für die Eingabe die sauberere Wahl.

Anschließend prüfen Sie Endpoint und Bucket mit dem eingebauten Test:

proxmox-backup-manager s3 endpoint list
proxmox-backup-manager s3 check offsite-s3 pbs-offsite-bucket

Verifizieren: s3 endpoint list zeigt offsite-s3, und s3 check endet ohne Fehlermeldung. Ein HTTP-403-Fehler weist auf fehlende Rechte des Schlüssels hin, ein Zertifikatsfehler auf einen fehlenden oder falschen Fingerabdruck.

Schritt 3: Datastore mit S3-Backend und lokalem Cache anlegen

Ein S3-Datastore speichert alle Inhalte im Bucket, braucht aber einen dauerhaften lokalen Cache, der Anfragen an den Anbieter reduziert. Proxmox empfiehlt 64 bis 128 GiB auf einem eigenen Datenträger oder einem ZFS-Dataset mit Quota. Ein Beispiel mit ZFS:

zfs create -o quota=128G -o mountpoint=/mnt/datastore/offsite-cache rpool/offsite-cache
proxmox-backup-manager datastore create offsite /mnt/datastore/offsite-cache \
  --backend type=s3,client=offsite-s3,bucket=pbs-offsite-bucket

PBS legt die Objekte mit dem Datastore-Namen als Präfix im Bucket ab. Ein S3-Datastore darf immer nur von einer PBS-Instanz gleichzeitig genutzt werden. Fällt der Server aus, binden Sie den Bucket auf einer neuen Installation unter demselben Datastore-Namen wieder ein:

proxmox-backup-manager datastore create offsite /mnt/datastore/offsite-cache-neu \
  --backend type=s3,client=offsite-s3,bucket=pbs-offsite-bucket \
  --reuse-datastore true --overwrite-in-use true

Diesen zweiten Befehl brauchen Sie nur im Notfall. Notieren Sie ihn zusammen mit Endpoint-Daten und Bucket-Namen in Ihrer Notfalldokumentation außerhalb des Servers.

Verifizieren: proxmox-backup-manager datastore show offsite zeigt das Backend type=s3 mit Ihrem Bucket, und in der Weboberfläche erscheint der Datastore offsite ohne Fehlerstatus.

Schritt 4: Offsite-Kopie per Sync-Job befüllen

Lassen Sie die Proxmox-VE-Hosts weiter auf Ihren schnellen lokalen Datastore sichern und kopieren Sie die Snapshots per Sync-Job in den S3-Datastore. Seit PBS 3.1 können Sync-Jobs auch zwischen zwei lokalen Datastores laufen; ohne --remote zieht der Job aus dem lokalen Quell-Datastore.

proxmox-backup-manager sync-job create offsite-sync \
  --store offsite \
  --remote-store local \
  --schedule '03:00' \
  --remove-vanished false \
  --comment 'Offsite-Kopie nach S3'

--remove-vanished false ist die wichtigste Einstellung: Snapshots, die im Quell-Datastore gelöscht werden, bleiben in der Offsite-Kopie erhalten. Wer den lokalen Datastore kompromittiert, löscht damit nicht automatisch auch die Kopie. Mit --verified-only true übertragen Sie nur bereits verifizierte Snapshots. Den ersten Lauf starten Sie von Hand:

proxmox-backup-manager sync-job run offsite-sync

Alternativ betreiben Sie den S3-Datastore auf einem zweiten PBS an einem anderen Standort und übertragen per Push-Sync. Seit PBS 4.2 kann ein Push-Sync die Snapshots vor dem Versand serverseitig verschlüsseln; das lohnt sich, wenn der Zielstandort weniger vertrauenswürdig ist. Legen Sie für jeden Push-Sync laut Dokumentation einen eigenen Remote mit eigenem Benutzer an.

Verifizieren: Der Task-Log des Sync-Jobs endet mit „TASK OK“, und unter Datastore > offsite > Inhalt erscheinen dieselben Backup-Gruppen wie im Quell-Datastore. Die Übersicht des Datastores zeigt die S3-Anfragezähler.

Schritt 5: Offsite-Kopie gegen Löschen absichern

Da Object Lock nicht nutzbar ist, kombinieren Sie die Schutzmechanismen, die PBS selbst bietet:

• Keine Löschrechte für Clients: Geben Sie Proxmox-VE-Hosts eigene API-Tokens mit der Rolle DatastoreBackup auf einem engen Pfad. Diese Rolle darf Backups anlegen, aber nicht löschen. Bereinigen Sie nur über Prune-Jobs auf dem Server.
• Geschützte Snapshots: Wichtige Stände, etwa den Monatsabschluss, markieren Sie mit proxmox-backup-client snapshot protected update <snapshot> true. Dann verweigert PBS Prune und manuelles Löschen. Das Flag wird beim Sync nicht übertragen; setzen Sie es im Datastore offsite selbst.
• Ungewöhnlichen Verkehr melden: In den Datastore-Optionen von S3-Datastores legen Sie Schwellwerte je Anfrageart fest, etwa für DELETE und POST. Wird ein Wert überschritten, verschickt PBS eine Benachrichtigung. Den Zähler setzen Sie periodisch zurück.
• Schlüssel trennen: Der S3-Schlüssel liegt auf dem PBS. Bewahren Sie einen zweiten Administratorzugang zum Anbieterkonto mit Mehrfaktor-Anmeldung getrennt auf, um den Bucket im Notfall sperren oder prüfen zu können.
• Echte Unveränderlichkeit: Brauchen Sie Datenträger, die technisch nicht löschbar sind, bietet PBS Bandsicherung mit WORM-Kassetten in einem eigenen Media-Pool mit Aufbewahrung keep.

proxmox-backup-manager user generate-token pve01@pbs backup
proxmox-backup-manager acl update /datastore/local/pve01 DatastoreBackup --auth-id 'pve01@pbs!backup'
proxmox-backup-manager datastore update offsite --counter-reset-schedule monthly

Verifizieren: Ein Löschversuch mit dem Token des Proxmox-VE-Hosts wird abgewiesen, ein geschützter Snapshot lässt sich in der Weboberfläche nicht entfernen, und in den Optionen von offsite sind Schwellwerte für Benachrichtigungen eingetragen.

Schritt 6: Prune, Garbage Collection und Verify einplanen

Auch der S3-Datastore braucht eine Aufbewahrungsregel, sonst wächst der Bucket dauerhaft. Wählen Sie für die Offsite-Kopie längere Fristen als lokal, weil manche Schadsoftware erst nach Tagen oder Wochen aktiv wird. Planen Sie danach die Garbage Collection: Sie löscht Chunks erst, wenn sie seit mehr als 24 Stunden und 5 Minuten von keinem Snapshot mehr verwendet werden.

proxmox-backup-manager prune-job create offsite-prune --store offsite \
  --schedule '05:00' --keep-daily 14 --keep-weekly 8 --keep-monthly 12
proxmox-backup-manager datastore update offsite --gc-schedule 'sat 06:00'
proxmox-backup-manager verify-job create offsite-verify --store offsite \
  --schedule 'sun 02:00' --outdated-after 30

Verify liest jeden Chunk aus dem Bucket und erzeugt dabei GET-Anfragen und ausgehenden Verkehr. Planen Sie Verify deshalb seltener als lokal und beobachten Sie die Zähler in der Übersicht. Testen Sie zusätzlich regelmäßig eine Wiederherstellung aus dem Datastore offsite in eine neue VM, nie über die laufende.

Verifizieren: proxmox-backup-manager garbage-collection status offsite zeigt einen erfolgreichen Lauf, verify-job list und prune-job list enthalten die neuen Jobs, und eine Test-VM startet aus einem Offsite-Snapshot.

Typische Fehler

• HTTP 403 vom Endpoint: Der Schlüssel hat nicht alle nötigen Rechte oder gilt für einen anderen Bucket. Rechte Get, Put, List und Delete prüfen.
• Garbage Collection scheitert oder Bucket wächst trotz Prune: Object Lock oder eine Aufbewahrungsregel des Anbieters blockiert DELETE. Für PBS-Buckets abschalten.
• Fehler bei Sammel-Löschungen: Der Anbieter unterstützt keine Batch-Deletes. Endpoint mit --provider-quirks delete-objects-via-delete-object aktualisieren.
• Speicher beim Anbieter voll: Aufräumarbeiten scheitern dann ebenfalls. Verwaiste Objekte des betroffenen Snapshots im Bucket entfernen und anschließend proxmox-backup-manager datastore s3-refresh offsite ausführen.
• Datastore lässt sich auf neuem Server nicht anlegen: Beim Wiedereinbinden fehlen --reuse-datastore true --overwrite-in-use true oder der Name weicht vom ursprünglichen ab.
• Hohe Anfragezahlen: Verify zu häufig oder Cache zu klein. Verify-Intervall verlängern, Cache an die empfohlene Größe anpassen.

Häufige Fragen

Kann ich Object Lock auf dem PBS-Bucket aktivieren?

Nein. PBS braucht Löschrechte für die Garbage Collection. Unveränderliche Backups auf S3 sind als Funktionswunsch im Proxmox-Bugtracker offen.

Kann ich den S3-Datastore als einziges Backup-Ziel verwenden?

Technisch ja. Für schnelle Wiederherstellungen und wegen der Anfragekosten ist ein lokaler Datastore als Primärziel mit S3 als Offsite-Kopie aber meist sinnvoller.

Dürfen zwei PBS-Server denselben Bucket nutzen?

Nicht denselben Datastore. Mehrere Datastores können sich einen Bucket teilen, weil PBS den Datastore-Namen als Präfix verwendet; betrieben wird jeder Datastore aber nur von einer Instanz.

Welche Version setzt diese Anleitung voraus?

PBS 4.2. In 4.0 und 4.1 war das S3-Backend eine Technologievorschau; die Provider-Option für Einzel-Löschungen und die Benachrichtigungsschwellen kamen mit 4.2.

Fazit

Mit PBS 4.2 ist eine Offsite-Kopie in S3 ohne Zusatzwerkzeuge möglich: Endpoint, Datastore mit Cache und ein lokaler Sync-Job reichen. Unveränderlich im Sinne von Object Lock ist diese Kopie nicht. Der Schutz entsteht aus einem Sync ohne Löschübernahme, knappen Rechten, Prune nur auf dem Server, Benachrichtigungen und regelmäßigen Restore-Tests. Wer echte WORM-Eigenschaften braucht, ergänzt Bänder.

Weiterführende Anleitungen und Quellen

• 3-2-1-Backup-Strategie praktisch umsetzen
• Backup-Restore-Test als feste Routine etablieren
• Ransomware-Notfallplan: die ersten 60 Minuten
• Proxmox VE installieren und Grundkonfiguration
• PBS-Dokumentation: Backup Storage (Datastores with S3 Backend, Ransomware Protection)
• PBS-Dokumentation: Managing Remotes & Sync
• PBS-Dokumentation: Maintenance Tasks (Prune, Garbage Collection, Verify)
• PBS-Dokumentation: User Management
• PBS-Dokumentation: Notifications (Schwellwerte für S3-Datastores)
• PBS-Dokumentation: proxmox-backup-manager
• Proxmox Backup Server Roadmap und Release Notes 4.2
• Proxmox Bugzilla 6780: Immutable backups on S3 storage