Proxmox Backup Server: Einrichtung und Backup-Strategie

Aus maxTechCorner

Auf einen Blick

Gilt fürProxmox Backup Server 4.x (aktuell 4.2) mit Proxmox VE 9.x; lokale Datastores, Wechsel-Datastores und S3-Backend
BereichServer-Software
Dauerca. 2–3 Stunden für Installation, Datastore, Einbindung und Jobs
Rechteroot@pam auf dem Backup-Server, Administrator in Proxmox VE
StandOktober 2026

Proxmox Backup Server einrichten und eine Backup-Strategie aufbauen schützt VMs und Container mit inkrementellen, deduplizierten, verschlüsselten Backups. Dieser Artikel zeigt die 3-2-1-Strategie mit dem Proxmox Backup Server (PBS), Datastore, Einbindung in Proxmox VE, Backup-Jobs, Aufbewahrung, Prüfung, Offsite-Kopie per Sync oder S3, die verschiedenen Restore-Wege und den Schutz vor Ransomware.

Backup-Strategie mit Proxmox Backup Server: Proxmox VE sichert VMs und Container im Modus Snapshot, clientseitig verschlüsselt, auf einen PBS außerhalb des Clusters; der Datastore dedupliziert, Prune-, Garbage-Collection- und Verify-Jobs halten ihn sauber. Kopien gehen per Sync-Job auf einen zweiten PBS, in einen S3-Objektspeicher oder auf Wechsel-Datastores; Restore als ganze VM, Live-Restore oder einzelne Datei.

Backup-Strategie: 3-2-1 mit Proxmox Backup Server

Grundlage ist die 3-2-1-Backup-Regel: drei Kopien der Daten, auf zwei unterschiedlichen Medien, davon eine außer Haus. Für eine Proxmox-Umgebung bedeutet das:

Kopie Ort Umsetzung mit PBS
1 Produktivdaten VMs und Container auf dem Proxmox-VE-Cluster
2 Backup im Haus PBS auf eigener Hardware, getrennt vom Cluster (anderer Brandabschnitt, wenn möglich)
3 außer Haus zweiter PBS an einem anderen Standort (Sync-Job), S3-Objektspeicher oder rotierende Wechselplatten
  • Eigene Hardware: Der PBS gehört nicht als VM auf den Cluster, den er sichert – fällt der Cluster aus, ist sonst auch das Backup weg. Ein PBS als VM ist allenfalls als zweite Kopie auf einem anderen System sinnvoll.
  • Arbeitsweise: PBS speichert Daten in Blöcken (Chunks) und legt jeden Block nur einmal ab (Deduplizierung). Nach der ersten Vollsicherung überträgt Proxmox VE dank Dirty-Bitmap nur geänderte Blöcke, jeder Snapshot ist trotzdem eine vollständige Wiederherstellungsbasis.
  • Hardware: Für den Datastore schnelle Datenträger einplanen – Garbage Collection und Verify lesen sehr viele kleine Dateien. Bewährt sind SSDs oder Festplatten-Pools mit einem SSD-Special-Device für die Metadaten in ZFS.
  • Ports: Weboberfläche und API des PBS laufen auf TCP 8007.

Installation und Datastore anlegen

Der PBS wird wie Proxmox VE über ein eigenes ISO-Image installiert (Debian 13 als Basis) oder als Paket proxmox-backup-server auf ein vorhandenes Debian 13 gesetzt. Danach die Weboberfläche unter https://pbs.firma.lan:8007 aufrufen, Repository wählen (Enterprise mit Subskription, sonst No-Subscription) und das System aktualisieren.

Den Datastore legen Sie unter Administration › Storage / Disks an (Reiter Directory oder ZFS) oder auf der Kommandozeile:

# ZFS-Spiegel aus zwei Platten und Datastore in einem Schritt
proxmox-backup-manager disk zpool create backup1 --devices sdb,sdc --raidlevel mirror --add-datastore true

# Alternativ: vorhandenes Verzeichnis als Datastore
proxmox-backup-manager datastore create backup1 /mnt/datastore/backup1
  • Namespaces gliedern einen Datastore, z. B. je Cluster, Standort oder Mandant (bis zu acht Ebenen tief). So können mehrere Cluster in denselben Datastore sichern und trotzdem von der Deduplizierung profitieren, ohne sich gegenseitig zu sehen.
  • Wechsel-Datastores (Removable Datastores) liegen auf einer USB- oder Wechselplatte mit ext4 oder xfs, werden unter /mnt/datastore/<name> eingehängt und mit Unmount bzw. proxmox-backup-manager datastore unmount <name> sicher ausgehängt. Seit PBS 4.0 kann ein Sync-Job beim Einhängen automatisch starten – ideal für rotierende Platten im Tresor.
  • S3-Backend: Seit PBS 4.2 ist ein S3-kompatibler Objektspeicher als Datastore nicht mehr Technologievorschau. Der Endpunkt wird unter Configuration › Remotes › S3 Endpoints hinterlegt; der Datastore braucht zusätzlich einen lokalen Cache (empfohlen 64–128 GiB auf eigener Platte oder eigenem ZFS-Dataset):
proxmox-backup-manager datastore create s3-offsite /mnt/datastore/s3-cache \
  --backend type=s3,client=mein-s3-endpunkt,bucket=pbs-offsite

Bucket und Zugangsdaten richten Sie vorher beim S3-Anbieter ein; seit PBS 4.1 lässt sich die Bandbreite zum S3-Speicher begrenzen.

Proxmox Backup Server in Proxmox VE einbinden

Für Proxmox VE einen eigenen Benutzer bzw. ein API-Token auf dem PBS anlegen – nicht root@pam – und ihm nur die Rolle DatastoreBackup geben. Diese Rolle darf sichern und eigene Backups wiederherstellen, aber nicht aufräumen (prunen) oder löschen:

# Auf dem PBS
proxmox-backup-manager user create pve-backup@pbs --password '<Passwort>'
proxmox-backup-manager acl update /datastore/backup1 DatastoreBackup --auth-id pve-backup@pbs
proxmox-backup-manager cert info | grep Fingerprint

In Proxmox VE unter Datacenter › Storage › Add › Proxmox Backup Server Server, Benutzer (mit Realm, z. B. pve-backup@pbs), Passwort, Datastore, optional Namespace und den Fingerprint eintragen. Auf der Kommandozeile:

pvesm add pbs pbs-backup1 --server 10.40.40.10 --datastore backup1 \
  --username pve-backup@pbs --fingerprint <Fingerprint> --password
pvesm set pbs-backup1 --encryption-key autogen
pvesm status --storage pbs-backup1

Clientseitige Verschlüsselung und Schlüsselsicherung

Mit --encryption-key autogen (in der Weboberfläche im Reiter Encryption) verschlüsselt Proxmox VE jedes Backup mit AES-256-GCM, bevor es den Knoten verlässt. Der Schlüssel liegt unter /etc/pve/priv/storage/<STORAGE-ID>.enc. Ohne diesen Schlüssel sind die Backups unbrauchbar – auch für Sie selbst, wenn der Cluster verloren ist.

# Schlüssel als QR-Code/Text für den Tresor ausgeben
proxmox-backup-client key paperkey /etc/pve/priv/storage/pbs-backup1.enc --output-format text > pbs-key.txt

Den Schlüssel im Passwortmanager, auf einem USB-Stick und als Papierausdruck getrennt vom Backup aufbewahren. Für größere Umgebungen kann zusätzlich ein RSA-Master-Key (master-pubkey) hinterlegt werden, mit dem sich die Schlüssel aller Backups wiederherstellen lassen – der private Teil gehört dann ebenfalls offline in den Tresor.

Backup-Jobs, Aufbewahrung, Garbage Collection und Verify

Backup-Jobs legen Sie unter Datacenter › Backup an: Knoten, Ziel-Storage, Zeitplan (z. B. täglich 21:00), Auswahl der Gäste (alle, einzelne oder per Pool) und den Modus Snapshot. Er sichert VMs im laufenden Betrieb; ist der QEMU Guest Agent aktiviert, friert er vorher die Dateisysteme ein (fs-freeze), damit Datenbanken konsistent gesichert werden. Der Modus stop ist konsistenter, kostet aber eine Auszeit. Bei VMs mit hoher Schreiblast hilft Fleecing im Reiter Advanced: alte Blöcke werden auf schnellem lokalem Storage zwischengespeichert, damit ein langsames Backup-Ziel den Gast nicht ausbremst.

vzdump 100 --storage pbs-backup1 --mode snapshot

Über Datacenter › Notifications melden Backup-Jobs Erfolg und Fehler per E-Mail, SMTP, Gotify oder Webhook.

Aufbewahrung (Prune) auf dem PBS

Weil der Proxmox-VE-Benutzer nur DatastoreBackup hat, legen Sie die Aufbewahrung als Prune-Job auf dem PBS an (Datastore › Reiter Prune & GC). Die Optionen keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly und keep-yearly werden in dieser Reihenfolge angewendet. Ein bewährtes KMU-Schema:

Option Wert Ergebnis
keep-last 3 die letzten drei Sicherungen, auch bei mehreren am Tag
keep-daily 14 zwei Wochen täglich
keep-weekly 8 zwei Monate wöchentlich
keep-monthly 12 ein Jahr monatlich
keep-yearly 3 drei Jahresstände (Aufbewahrungspflichten prüfen)

Der eingebaute Prune-Simulator zeigt vorab, welche Stände erhalten bleiben. Einzelne Snapshots lassen sich als protected markieren; sie zählen nicht zur Aufbewahrung und werden nie gepruned.

Garbage Collection und Verify

Prune entfernt nur die Verweise. Den Speicher gibt erst die Garbage Collection frei: Sie markiert alle noch benutzten Chunks und löscht danach Chunks, die länger als 24 Stunden und 5 Minuten nicht angefasst wurden. Planen Sie sie täglich nach den Prune-Jobs (Reiter Prune & GC).

Verify-Jobs (Reiter Verify Jobs) lesen die Chunks und prüfen die Prüfsummen – nur so fällt ein defekter Datenträger auf, bevor Sie ein Backup brauchen. Bereits geprüfte Snapshots lassen sich überspringen und nach einer Frist erneut prüfen; Proxmox empfiehlt, alle Backups mindestens monatlich neu zu verifizieren. Ergänzend gilt: Nur ein getesteter Restore ist eine Backup-Verifizierung.

Offsite-Kopie: Sync-Jobs, S3 und Wechsel-Datastores

Für die dritte Kopie synchronisiert ein Sync-Job Snapshots von einem PBS zu einem anderen. Zuerst den entfernten PBS unter Configuration › Remotes eintragen, dann am Datastore im Reiter Sync Jobs den Job anlegen.

proxmox-backup-manager remote create pbs-zentrale --host 192.0.2.20 \
  --userid sync@pbs --password '<Passwort>' --fingerprint <Fingerprint>
Richtung Ablauf Einsatz
Pull (Standard) der Offsite-PBS holt die Daten vom Haupt-PBS empfohlen: der Offsite-PBS hat Zugangsdaten zur Quelle, nicht umgekehrt
Push der Haupt-PBS schreibt auf den entfernten PBS wenn der Offsite-Standort keine eingehende Verbindung aufbauen darf
  • Pull ist aus Sicherheitssicht vorzuziehen: Ein Angreifer auf dem Haupt-PBS findet dort keine Zugangsdaten zur Kopie.
  • Push braucht auf der Gegenseite die Berechtigung Remote.DatastoreBackup; Löschrechte (Remote.DatastorePrune, Remote.DatastoreModify) nur vergeben, wenn remove-vanished wirklich gewünscht ist. Seit PBS 4.2 kann ein Push-Job unverschlüsselte Snapshots vor der Übertragung serverseitig verschlüsseln.
  • encrypted-only und verified-only übertragen nur verschlüsselte bzw. geprüfte Snapshots; worker-threads synchronisiert mehrere Gruppen parallel; rate-in/rate-out begrenzen die Bandbreite.
  • Alternativ dient ein Datastore mit S3-Backend bei einem deutschen Anbieter als Offsite-Ziel, befüllt per Sync-Job vom lokalen Datastore. Mit aktivierter Objektsperre (Object Lock) beim Anbieter wird daraus ein Immutable Backup – Details vorher mit dem Anbieter klären.
  • Wechsel-Datastores bleiben die einfachste Air-Gap-Lösung: Platte einhängen, Sync läuft automatisch, Platte aushängen und auswärts lagern.

Wiederherstellung: Restore, Single-File und Live-Restore

  • Ganze VM oder Container: In Proxmox VE am PBS-Storage im Reiter Backups den Snapshot wählen und Restore klicken; auf der Kommandozeile mit qmrestore bzw. pct restore. Eine neue VMID verhindert, dass der noch vorhandene Gast überschrieben wird.
  • Live-Restore: Die VM startet sofort, die Daten werden im Hintergrund nachgeladen (Kontrollkästchen im Restore-Dialog bzw. qmrestore … --live-restore 1). Die Lesegeschwindigkeit ist währenddessen eingeschränkt, und bricht der Restore ab, sind in der Zwischenzeit geschriebene Daten meist verloren – geeignet, um einen kleinen, wichtigen Server schnell wieder bereitzustellen.
  • Einzelne Dateien: Mit File Restore im Reiter Backups durchsuchen Sie ein Backup und laden Dateien oder Ordner herunter. Für VM-Images startet Proxmox dafür kurzzeitig eine Hilfs-VM. Das funktioniert nur mit Backups auf einem PBS.
  • Notfall ohne Cluster: Dokumentieren, wie ein neu installierter Knoten den PBS einbindet (Fingerprint, Zugangsdaten, Schlüssel).
  • Restore-Test: Mindestens quartalsweise eine VM in ein isoliertes Netz zurückspielen und die Anwendung prüfen.

Ransomware-Schutz und Hinweise

Angreifer zielen gezielt auf Backups. Die Rechtetrennung des PBS ist der wichtigste Schutz gegen Ransomware:

  • Proxmox VE nutzt nur DatastoreBackup – wer den Cluster übernimmt, kann vorhandene Backups nicht löschen oder prunen. Aufbewahrung und Löschung steuert ausschließlich der PBS.
  • Der PBS ist kein Mitglied der Windows-Domäne, hat ein eigenes root-Passwort, Zwei-Faktor-Anmeldung für alle Administratoren und steht in einem eigenen Netzsegment, das nur Port 8007 von den Proxmox-Knoten zulässt.
  • Die Offsite-Kopie wird per Pull geholt und hat eigene Zugangsdaten; der Haupt-PBS kennt sie nicht. Siehe auch Ransomware-resilientes Backup.
  • Typische Fehler: PBS als VM im selben Cluster, Verschlüsselungsschlüssel nur auf den Clusterknoten, keine Garbage Collection (Datastore läuft voll), nie getesteter Restore.
  • Wenn Sie die Offsite-Kopie nicht selbst betreiben möchten, bietet das Cloud-Backup von m.a.x. it einen externen Sicherungsstandort.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen