Proxmox Backup Server auf einem VPS einrichten

Was ein Proxmox Backup Server auf einem VPS tatsächlich bietet

Ein Proxmox Backup Server (PBS) auf einem VPS ist ein externes Sicherungsziel, das dasselbe Protokoll verwendet wie Ihr Proxmox-VE-Cluster (Virtual Environment). Dadurch ist jede Sicherung nach der ersten inkrementell, wird über mehrere Gäste hinweg dedupliziert, vor dem Verlassen Ihres Standorts verschlüsselt und anschließend überprüfbar. Sie mieten einen VPS mit einem Block-Volume, installieren PBS auf Debian 13, erstellen auf diesem Volume einen Datastore und fügen ihn in Proxmox VE als Speicher vom Typ pbs hinzu. Die Installation dauert zehn Minuten. Ob die Sicherung ein Jahr später noch einen Nutzen hat, hängt von allem ab, was danach kommt: Namespaces, Garbage Collection, die Verwaltung der Schlüssel und eine Wiederherstellung, die Sie tatsächlich durchgeführt haben.

Der Grund für PBS anstelle des Kopierens von vzdump-Dateien auf einen gemieteten Datenträger ist der Chunk-Speicher. Der Client teilt jede Gastfestplatte in Chunks von etwa 4 MiB auf, hasht diese und lädt nur die Chunks hoch, die im Datastore noch nicht vorhanden sind. Bei einer laufenden virtuellen Maschine verfolgt QEMU nach der ersten Sicherung geänderte Blöcke in einer Dirty-Bitmap. Beim nächsten Lauf werden daher nur diese Blöcke von der lokalen Festplatte gelesen. Ein Gast mit 200 GB, bei dem sich täglich 3 GB ändern, überträgt täglich etwa 3 GB. Dadurch funktionieren ein heimischer Uplink und ein gemietetes Volume zusammen. Deshalb ist ein VPS als externes Sicherungsziel besser als ein Ersatzlaufwerk im Haus eines Freundes. Wenn Sie noch entscheiden, wo der Hypervisor selbst betrieben werden soll, behandelt Proxmox zu Hause oder auf einem gemieteten VPS diese Frage separat.

Dimensionieren Sie das Volume vor dem Mieten

Die Dimensionierung ist eine Berechnung mit Ihren eigenen Werten. Ermitteln Sie den tatsächlich von jedem Gast verwendeten Speicherplatz, nicht die Größe seiner virtuellen Festplatte. Addieren Sie anschließend die tägliche Änderung, multipliziert mit der Anzahl der Tage, für die Sie die Daten aufbewahren. Komprimierung und Deduplizierung verbessern diesen Wert. Betrachten Sie das Ergebnis daher als Obergrenze und nicht als Zielwert.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Diese Zeilen sind ein Rechenbeispiel und keine Messung. Lesen Sie den belegten Speicherplatz in jedem Gast aus df -h ab. Ermitteln Sie die tägliche Änderung aus der Größe des zweiten und dritten Backups im PBS-Aufgabenprotokoll, sobald diese vorhanden sind.

Der Mail-Gast im Beispiel verwendet 120 GB und ändert sich um etwa 3.0 GB pro Tag. Daher benötigen dreißig tägliche Snapshots ungefähr 210 GB: eine vollständige Kopie plus die Änderungen von dreißig Tagen. Addieren Sie die letzte Spalte für alle 3 Gäste. Das ergibt insgesamt etwa 619 GB. Rechnen Sie ein Fünftel für Indizes, Metadaten und den von der Garbage Collection benötigten freien Speicher hinzu. Damit ergibt sich ein Volume mit 1 TB.

Der restliche Plan ist einfach. PBS arbeitet mit 2 GB RAM problemlos und mit 4 GB komfortabel, weil die aufwendige Verarbeitung auf der Clusterseite stattfindet: Der Proxmox VE-Knoten liest die Festplatten der Gäste und übernimmt Chunking und Hashing. Die VPS schreibt Chunks und führt die beiden rechenintensiven Aufgaben Garbage Collection und Verifizierung aus. Mieten Sie den Datastore als separates Block-Volume statt als eine große Root-Festplatte. Ein Volume können Sie später vergrößern, ohne den Server neu aufzubauen.

Proxmox Backup Server unter Debian 13 installieren

Im August 2026 ist die aktuelle Kombination Proxmox Backup Server 4 unter Debian 13 mit dem Codenamen trixie. Ältere Anleitungen kombinieren PBS 2 mit Debian 11. Der Codename ist Bestandteil der Repository-Definition. Wenn Sie den Suite-Namen aus einer älteren Anleitung kopieren, meldet apt daher, dass die Release-Datei fehlt. Verwenden Sie ein unverändertes Debian-13-Image. Führen Sie alle folgenden Befehle als root oder mit sudo wie angegeben aus.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Die Prüfsumme muss 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 lauten. Falls nicht, brechen Sie ab. Ein falscher Keyring bedeutet, dass Sie Pakete installieren würden, die mit einem nicht geprüften Schlüssel signiert wurden.

Schreiben Sie /etc/apt/sources.list.d/pbs.sources mit dem No-Subscription-Repository. Dieses Repository ist für einen Server ohne Supportvertrag vorgesehen:

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

sudo apt update
sudo apt install -y proxmox-backup-server

Die Weboberfläche ist über den HTTPS-Port 8007 erreichbar. Melden Sie sich als root@pam mit dem Systempasswort von root an. PBS authentifiziert diesen Benutzer über PAM (pluggable authentication modules), also über dieselben Konten, die das Betriebssystem verwendet. Das Zertifikat ist selbst signiert, und Ihr Browser wird darauf hinweisen. Der Fingerabdruck dieses Zertifikats ist der Wert, den Proxmox VE später fest hinterlegt. Die Warnung ist daher erwartbar und kein Problem, das behoben werden muss.

Port 8007 stellt ein Anmeldeformular im öffentlichen Internet bereit. Lassen Sie ihn daher nicht für alle Quellen offen. Eine nftables-Datei reicht dafür aus. /etc/nftables.conf löscht den aktuellen Ruleset. Überspringen Sie diesen Schritt, wenn auf diesem Server bereits eine andere Komponente die Firewall verwaltet.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Wenden Sie die Konfiguration mit sudo systemctl enable --now nftables an. Lassen Sie dabei eine zweite SSH-Sitzung geöffnet: policy drop plus ein Tippfehler in der SSH-Regel kann Sie von Ihrem eigenen Server aussperren. Ersetzen Sie 203.0.113.7 durch die Adresse, von der aus Ihr Cluster die Verbindung herstellt. Wenn diese Adresse dynamisch ist, erweitern Sie die Regel entweder auf den Bereich Ihres Providers oder beenden Sie die Verbindung in einem Tunnel. Beachten Sie außerdem, dass die meisten VPS-Portale eine separate Netzwerk-Firewall vor dem Server betreiben, die denselben Port zulassen muss.

Den Datenspeicher auf ein eigenes Volume legen

Der Datenspeicher darf nicht auf dem Root-Dateisystem liegen. Wenn ein Datenspeicher ein gemeinsam genutztes Root-Dateisystem füllt, schlägt die Sicherung fehl. Außerdem fallen alle anderen Dienste auf dem Server aus, einschließlich der Protokollierung, die Sie zur Ursachenanalyse benötigen. Binden Sie das Block-Volume ein, formatieren Sie es, mounten Sie es und erstellen Sie den Datenspeicher erst danach innerhalb des Mount-Punkts.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Übernehmen Sie den Gerätenamen aus lsblk. Bei den meisten KVM-Images lautet er /dev/vdb, bei anderen /dev/sdb. Eine Annahme ist jedoch niemals sicher. Tragen Sie den Mount anhand des Labels in /etc/fstab ein. Dadurch kann eine Umbenennung des Geräts nach einem Reboot den Datenspeicher nicht auf das falsche Laufwerk verweisen lassen:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt sollte das Gerät, den Pfad und Optionen einschließlich rw,relatime ausgeben. In dieser einen Zeile können zwei Fehler verborgen sein. Wenn der Mount nicht vorhanden ist und Sie trotzdem den Datenspeicher erstellen, schreibt PBS unterhalb des Mount-Punkts in das Root-Dateisystem. Der nächste erfolgreiche Mount blendet diese Daten aus, ohne sie zu löschen. Der Datenspeicher wirkt dann leer, während das Root-Dateisystem voll bleibt. Wenn die Optionen noatime enthalten, verweigert PBS den Betrieb. Beim Erstellen des Datenspeichers und erneut bei jeder Garbage Collection führt PBS eine Sicherheitsprüfung der Zugriffszeit aus.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Dadurch wird ein Verzeichnis .chunks mit 65536 Unterverzeichnissen angelegt, die von 0000 bis ffff benannt sind. Ein Datenspeicher besteht aus Hunderttausenden kleinen Dateien, nicht aus wenigen großen Dateien. Daraus folgen zwei Dinge. Das Kopieren eines Datenspeichers mit einem gewöhnlichen Tool auf Dateiebene ist so langsam, dass es unbrauchbar ist. Außerdem ist ein Provider-Volume-Snapshot, der während laufender Sicherungen erstellt wird, keine konsistente Kopie des Datenspeichers. Aus demselben Grund ersetzen Snapshots keine Sicherungen auch an anderer Stelle keine Backups.

Namespaces verhindern Kollisionen zwischen Hosts

Ein Datenspeicher ist standardmäßig flach aufgebaut. Backups werden als vm/100, ct/101 und host/<name> bezeichnet. Wenn zwei Cluster jeweils einen Gast mit der ID 100 haben und in dieselbe Gruppe schreiben, vermischen sich ihre Snapshots. Eine für einen Cluster definierte Aufbewahrungsregel zählt dann auch die Snapshots des anderen Clusters. Namespaces geben jeder Quelle innerhalb eines Datenspeichers einen eigenen Baum.

Erstellen Sie die Namespaces auf dem PBS-Host. Das Argument --repository hat die Form [[auth-id@]server[:port]:]datastore. Für einen lokalen Namespace lautet es root@pam@localhost:store1. Der Befehl fordert das root-Passwort an.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

Die Deduplizierung wird durch diese Aufteilung nicht beeinträchtigt. Chunks werden im gesamten Datenspeicher gemeinsam verwendet. Daher belegen zehn Debian-Gäste, die auf drei Namespaces verteilt sind, nur eine Kopie des Basissystems. Das spricht für einen Datenspeicher mit Namespaces statt für einen Datenspeicher pro Host: Separate Datenspeicher haben separate Chunk-Pools. Separate Chunk-Pools führen dazu, dass dieselbe Debian-Installation mehrfach gespeichert wird.

Geben Sie jeder Quelle ein eigenes Konto mit Berechtigungen, die auf den jeweiligen Namespace beschränkt sind. Ein API-Token (Application Programming Interface) ist eine Zugangsdaten, die zu einem Benutzer gehört und eigene Berechtigungen besitzt. Das ist für einen möglicherweise gestohlenen Rechner die richtige Konfiguration.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Der Token-Befehl gibt das Secret genau einmal aus:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Kopieren Sie es jetzt, da PBS keine Form davon speichert, die später erneut angezeigt werden kann. Prüfen Sie den Befehl für die Zugriffskontrolle zweimal. Er nennt den Token backup@pbs!pve-home und nicht den Benutzer, da die Berechtigungen eines Tokens nur anhand von Einträgen berechnet werden, die den Token selbst nennen. Ein Eintrag ausschließlich für backup@pbs lässt den Token ohne jeden Zugriff. Das erste Backup schlägt dann wegen fehlender Berechtigungen fehl und nicht wegen eines im Netzwerk sichtbaren Problems. Auch der Pfad ist entscheidend: Ein auf /datastore/store1/pve-home beschränkter Token kann im Namespace des Büros weder lesen noch löschen. Dadurch kann ein kompromittierter Cluster nicht die Historie eines anderen Standorts zerstören.

VPS als Backup-Speicher in Proxmox VE hinzufügen

Lesen Sie zuerst den Fingerabdruck des Zertifikats auf dem PBS-Host aus.

sudo proxmox-backup-manager cert info | grep Fingerprint

Führen Sie den Befehl anschließend auf einem beliebigen Clusterknoten aus:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Setzen Sie den ausgegebenen Wert cert info anstelle des Platzhalters in der dritten Zeile ein. Wenn Sie --password ohne Wert übergeben, fordert pvesm Sie dazu auf. Das Token-Geheimnis bleibt dadurch aus der Shell-History heraus. Es wird unter /etc/pve/priv/storage/pbs-offsite.pw gespeichert. Die Speicherkonfiguration selbst wird unter /etc/pve/storage.cfg abgelegt. Diese Konfiguration wird auf jeden Clusterknoten repliziert. Sie müssen den Speicher daher nur einmal für den gesamten Cluster konfigurieren.

--prune-backups keep-all=1 weist Proxmox VE an, nichts zu löschen. Die Aufbewahrung wird auf der PBS-Seite festgelegt, wie weiter unten beschrieben. Der Grund ist wichtig: Das Token benötigt dann keine Berechtigung zum Löschen. Ein Cluster, der durch Ransomware verschlüsselt wurde, kann die ausgelagerte Historie, die ihn retten soll, dadurch nicht erreichen und bereinigen.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status gibt active in der Statusspalte aus. Daneben werden der gesamte und der belegte Speicher des Datastores angezeigt. inactive bedeutet, dass der Knoten keine TLS-Sitzung (Transport Layer Security) zu Port 8007 aufbauen konnte. Das weist auf ein Firewall- oder Fingerabdruckproblem hin, nicht auf ein Problem mit den Zugangsdaten.

Das erste Backup lädt alle Daten hoch. Berechnen Sie die benötigte Zeit daher vorher. 200 GB entsprechen 1600 Gigabit. Eine Uplink-Bandbreite von 100 Mbit überträgt 0.1 Gigabit pro Sekunde. Die theoretische Mindestdauer beträgt damit etwa viereinhalb Stunden. In der Praxis dauert es länger. Starten Sie das Backup zu einem Zeitpunkt, an dem Sie die Bandbreite nicht benötigen. Bei jedem weiteren Lauf werden nur neue Chunks übertragen.

Clientseitige Verschlüsselung und der Speicherort des Schlüssels

Der VPS ist ein Computer, der Ihnen nicht gehört. Verschlüsseln Sie auf dem Client. Der Datenspeicher enthält dann nur Datenblöcke, die der Anbieter nicht lesen kann.

sudo pvesm set pbs-offsite --encryption-key autogen

Damit wird ein neuer Schlüssel nach /etc/pve/priv/storage/pbs-offsite.enc geschrieben. Die Datei ist nur für root lesbar und wird zusammen mit dem restlichen /etc/pve repliziert. Ab dem nächsten Backup verschlüsselt der Client jeden Datenblock, bevor er ihn überträgt. Der Server kann weiterhin Ihre Snapshots und deren Größe auflisten. Ihren Inhalt kann er nicht lesen.

Jetzt kommt der Teil, der daraus ein Backup und kein Haftungsrisiko macht. Ein generierter Schlüssel hat keine Passphrase und existiert nur auf dem Cluster, den er schützt. Wird dieser Cluster gestohlen oder von jemand anderem verschlüsselt, enthält der VPS Daten, die niemand öffnen kann. Kopieren Sie den Schlüssel an dem Tag vom Cluster weg, an dem Sie ihn erstellen.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey gibt den Schlüssel als Dokument aus. Es ist für den Ausdruck auf Papier und die Aufbewahrung an einem anderen Ort vorgesehen. Behandeln Sie die Datei selbst als Geheimnis, denn jeder, der sie besitzt, kann jedes damit erstellte Backup entschlüsseln. Für größere Umgebungen unterstützt PBS außerdem einen Master Key. Dabei handelt es sich um ein mit proxmox-backup-client key create-master-key erstelltes RSA-Schlüsselpaar (Rivest Shamir Adleman). Jedes Backup speichert dabei seinen eigenen Verschlüsselungsschlüssel, der mit dem öffentlichen Schlüssel verschlüsselt wird. Der private Schlüssel bleibt für die Wiederherstellung offline.

Eine Folge dieses Designs sollten Sie kennen, bevor Sie beginnen, nicht erst danach. Bei verschlüsselten Backups wird der Digest des Datenblocks aus dem Klartextinhalt zusammen mit dem Verschlüsselungsschlüssel berechnet. Daher erzeugen zwei identische Datenblöcke, die mit unterschiedlichen Schlüsseln verschlüsselt wurden, unterschiedliche Digests und werden niemals miteinander dedupliziert. Wenn Sie den Schlüssel ändern, lädt das nächste Backup alle Daten erneut hoch. Die alten Datenblöcke bleiben erhalten, bis ihre Snapshots bereinigt und gesammelt werden. Entscheiden Sie sich vor dem ersten Upload für oder gegen Verschlüsselung.

Prune markiert, Garbage Collection gibt Speicher frei

Dies ist der Abschnitt, der oft übersprungen wird, obwohl er das Volume füllt. Beim Pruning eines Snapshots werden dessen Metadaten entfernt: das Manifest, die Indizes, das Log und die Notizen. Chunks werden dabei nicht gelöscht. Chunks werden von mehreren Snapshots gemeinsam verwendet. Daher lässt sich erst feststellen, dass ein Chunk nicht mehr benötigt wird, wenn alle verbleibenden Indizes gelesen wurden. Diese Aufgabe übernimmt die Garbage Collection. Ein Datastore mit einem Prune-Zeitplan, aber ohne Zeitplan für die Garbage Collection wächst daher unbegrenzt.

Konfigurieren Sie beides. Zuerst die Aufbewahrung, mit einem Job pro Namespace:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Konfigurieren Sie anschließend den Zeitplan für die Collection auf dem Datastore. Der Job sollte einige Stunden nach dem Prune-Job und außerhalb des Backup-Zeitfensters laufen:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Überprüfen Sie die Trennung einmal auf dem PBS-Host:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Führen Sie den Prune-Job und anschließend df aus. Die Anzeige für den belegten Speicher ändert sich nicht. Führen Sie danach die Garbage Collection und erneut df aus. Jetzt ändert sie sich.

Die Garbage Collection läuft in zwei Phasen. In der ersten Phase werden alle Indizes im Datastore durchlaufen. Dabei wird die Zugriffszeit jedes von diesen Indizes referenzierten Chunks aktualisiert. In der zweiten Phase werden die Chunks gelöscht, deren Zugriffszeit älter als der Stichtag ist. Dieser liegt 24 Stunden und 5 Minuten vor dem Start des Laufs oder entspricht dem Start des ältesten noch laufenden Backups, je nachdem, welcher Zeitpunkt früher liegt. Dieser zeitliche Puffer ist erforderlich, weil Linux Dateisysteme standardmäßig mit relatime einhängt. Dadurch wird die Zugriffszeit ungefähr einmal täglich statt bei jedem Lesezugriff aktualisiert. Ein vor einer Stunde geschriebener Chunk wird daher niemals gelöscht, auch wenn ihn bisher kein Index referenziert. Speicher, der durch einen Prune-Lauf freigegeben wurde, wird bei der ersten Collection sichtbar, die mehr als einen Tag nach dem letzten Zugriff auf den Chunk läuft. Wenn ein Datastore scheinbar keinen Speicher freigegeben hat, liegt das häufig daran, dass dieser Zeitraum noch nicht abgelaufen ist.

Auf einem kleinen VPS ist dies der aufwendigste Job, weil für jede Chunk-Datei auf dem Volume ein stat-Aufruf ausgeführt wird. Das Aufgabenlog endet mit einer Zusammenfassung der entfernten Daten und der Daten, deren Löschung wegen der Karenzzeit noch aussteht. Wenn viele Chunks ausstehen, führen Sie den Job am nächsten Tag erneut aus. PBS stellt gc-atime-safety-check und gc-atime-cutoff als Tuning-Optionen für den Datastore bereit. Beide Optionen sollten unverändert bleiben. Sie sind für Speicher vorgesehen, der keine Zugriffszeiten aufzeichnen kann. Wird die Sicherheitsprüfung auf einem mit noatime eingehängten Dateisystem deaktiviert, können Chunks verloren gehen, auf die noch laufende Snapshots verweisen.

Die Überprüfung bestätigt, dass die Chunks weiterhin lesbar sind

Eine Sicherung, die fehlerfrei hochgeladen wurde, kann ein Jahr später trotzdem nicht mehr lesbar sein. Bei der Überprüfung werden die Chunks erneut gelesen und mit den im Index gespeicherten Prüfsummen verglichen. Schäden werden dadurch planmäßig erkannt und nicht erst bei einer Wiederherstellung.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Halten Sie die Anzahl der Threads auf einem kleinen VPS niedrig. Die Überprüfung wird durch Datenträger und CPU begrenzt. Andernfalls konkurriert sie mit den anderen Prozessen auf dem System. Verwenden Sie für die Zeitplanung im Webinterface des Datastores den Tab Verify Jobs: Ein wöchentlicher Job, der bereits überprüfte Snapshots überspringt und alle Snapshots erneut überprüft, die älter als 30 Tage sind, deckt den gesamten Store mit der Zeit ab, ohne Arbeiten zu wiederholen.

Ein Snapshot, der die Überprüfung nicht besteht, wird in der Datastore-Ansicht als fehlgeschlagen markiert. Ignorieren Sie ihn nicht. Chunks werden gemeinsam verwendet. Daher führt ein einzelner beschädigter Chunk aus einem Basis-Image in der Regel dazu, dass jeder darauf verweisende Snapshot fehlschlägt. Vergessen Sie die fehlgeschlagenen Snapshots und führen Sie eine neue Sicherung aus. Dabei werden die fehlenden Chunks erneut hochgeladen. Wenn weiterhin Fehler auftreten, prüfen Sie den Speicher unter dem Datastore als mögliche Ursache. Richten Sie außerdem eine Überwachung des Datenträgerzustands auf dem VPS ein, damit Sie über einen Laufwerksfehler informiert werden, bevor der Verify-Job ihn erkennt.

Einen Restore testen und anschließend ohne den Cluster testen

Sie wissen erst dann, dass ein Backup funktioniert, wenn Sie es wiederhergestellt haben. Die beiden Tests prüfen unterschiedliche Dinge.

Gesamten Gast auf dem Cluster:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

Die erste Spalte von pvesm list enthält die Volume-ID. Der Zeitstempel ist Bestandteil dieser ID. Übernehmen Sie daher Ihre eigene ID, statt das Beispiel einzugeben. Stellen Sie den Gast mit einer ungenutzten Gast-ID auf einem anderen Storage wieder her. Starten Sie ihn anschließend mit getrennter Netzwerkschnittstelle. Stellen Sie niemals einen laufenden Gast wieder her, um die Funktionsfähigkeit eines Backups zu prüfen. Wenn der Restore dabei zur Hälfte fehlschlägt, verlieren Sie sonst auch die funktionierende Kopie.

Der zweite Test wird fast nie ausgeführt. Gehen Sie davon aus, dass das Gebäude mit dem Cluster nicht mehr existiert. Stellen Sie den Gast von einem Rechner wieder her, der nie Teil des Clusters war. Fügen Sie auf einem beliebigen Debian-13-Rechner das Repository nur für den Client hinzu, wie in /etc/apt/sources.list.d/pbs-client.sources:

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

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Ersetzen Sie die drei Platzhalter in Anführungszeichen durch Ihre eigenen Werte. Übernehmen Sie den Archivnamen in der letzten Zeile aus der Ausgabe von snapshot files. Damit weisen Sie etwas nach, was der erste Test nicht prüfen kann: Ihre Kopie der Schlüsseldatei kann echte Daten entschlüsseln, und Sie können den Client von einem Rechner aus bedienen, der die Konfiguration Ihres Clusters nie enthalten hat. Notieren Sie die vier benötigten Werte: den Repository-String, das Token-Secret, den Fingerabdruck und die Schlüsseldatei. Bewahren Sie sie gemeinsam an dem Ort auf, auf den Ihr Notfallplan verweist.

Was die Deduplizierung mit Ihren Plattenkosten macht und was nicht

Deduplizierung ist real und funktioniert über den gesamten Datastore hinweg. Zehn Debian-Gäste nutzen gemeinsam eine Kopie des Basissystems. Der zweite identische Gast verursacht daher nahezu keinen zusätzlichen Speicherbedarf. Auch beim Upload wird Bandbreite eingespart, weil der Client für jeden Chunk, den der Server bereits besitzt, statt der Daten nur eine Prüfsumme sendet.

Was sie nicht leistet, sollte klar benannt werden.

• Sie verkleinert keine Daten, die sich ändern. Eine Datenbank, die jede Nacht große Teile ihrer Dateien neu schreibt, erzeugt jede Nacht neue Chunks. Die Aufbewahrung vervielfacht diese.
• Sie funktioniert nicht über eine Grenze zwischen Verschlüsselungsschlüsseln hinweg, wie oben beschrieben.
• Sie funktioniert nicht über eine Datastore-Grenze hinweg. Genau das ist der Grund für Namespaces.
• Sie verhindert nicht, dass sich ein Volume füllt. Wenn der Datastore voll ist, schlagen Backups fehl. Dann bleiben nur ein größeres Volume oder eine kürzere Aufbewahrungsdauer.

Setzen Sie darunter keine weitere Deduplizierungsschicht ein. Die Chunks treffen bereits dedupliziert und vom Client komprimiert ein. Eine ZFS-Deduplizierung unter einem Datastore würde daher RAM für die Suche nach Übereinstimmungen verwenden, die bereits vor dem Schreiben entfernt wurden. Normales ext4 oder xfs auf dem Volume ist hier die richtige Wahl.

Die Weboberfläche zeigt für den Datastore einen Deduplizierungsfaktor an. Diese Zahl beschreibt Ihre Gäste. Nur mit ihr sollten Sie planen, weil veröffentlichte Quoten die Daten anderer Betreiber beschreiben. Wenn Sie zusätzlich Backups auf Dateiebene für Rechner benötigen, die keine Proxmox-Gäste sind, führen Sie diese parallel auf demselben VPS aus: PBS ist ein hypervisorbewusstes Ziel für vollständige Gäste, während restic und BorgBackup auf Verzeichnisse zeigen. restic-Backups auf einen VPS eignen sich für Laptops und eigenständige Server, für die PBS nie vorgesehen war.

Fehlerbilder und ihre Bedeutung

Der Speicher wird als inaktiv angezeigt. pvesm status --storage pbs-offsite gibt inactive aus, wenn der Knoten keine TLS-Sitzung mit Port 8007 aufbauen kann. Prüfen Sie zuerst die Firewall auf dem VPS, anschließend die separate Netzwerk-Firewall des Providers und danach den Fingerabdruck. Ein Fingerabdruck, der nicht mehr zum Zertifikat passt, führt sichtbar zum gleichen Fehlerbild wie ein blockierter Port. Er ändert sich jedes Mal, wenn das Zertifikat ersetzt wird.

Das erste Backup scheitert an den Berechtigungen. Der Eintrag für die Zugriffskontrolle muss das Token und nicht den Benutzer angeben. Außerdem muss er den Namensraum abdecken, auf den der Speicher verweist. Prüfen Sie beides im Webinterface auf der Registerkarte für die Berechtigungen des Datastores, bevor Sie an anderer Stelle suchen.

Die Garbage Collection lässt sich nicht starten. Die Sicherheitsprüfung der Zugriffszeit ist fehlgeschlagen. Das bedeutet fast immer, dass das Dateisystem des Datastores mit noatime eingehängt ist. Führen Sie findmnt -no OPTIONS /mnt/datastore/store1 aus, um dies zu bestätigen, korrigieren Sie die Option in /etc/fstab und hängen Sie das Dateisystem erneut ein. Deaktivieren Sie die Prüfung nicht, um den Fehler zu umgehen.

Der Datastore wächst nur weiter. Prune-Jobs laufen, aber es wird kein Speicher freigegeben. Entweder ist kein Zeitplan für die Garbage Collection eingerichtet, oder jede Sammlung liegt innerhalb des 24-Stunden-Schutzzeitraums, weil sie unmittelbar nach den Backups ausgeführt wird. Prüfen Sie den Zeitplan mit proxmox-backup-manager datastore show store1.

Ein Backup, das früher schnell war, dauert mehrere Stunden. Ein Gast, der gestoppt, migriert oder wiederhergestellt wurde, verliert seine Dirty-Bitmap. Beim nächsten Lauf liest die Cluster-Seite deshalb die gesamte Festplatte ein, obwohl nur sehr wenige Daten hochgeladen werden. Das Aufgabenprotokoll zeigt eine lange Laufzeit mit einer geringen Upload-Menge. Beim darauffolgenden Lauf ist die Ausführung wieder schnell. Wenn stattdessen jeder Job auf dem VPS langsam ist, liegt die Ursache normalerweise außerhalb des Datastores. Messen Sie zuerst CPU-Steal-Zeit durch einen stark ausgelasteten Nachbarn.

FAQ

Warum wächst der Datastore meines Proxmox Backup Server weiter, wenn der Prune-Job läuft?

Weil das Pruning nur die Snapshot-Metadaten entfernt: das Manifest, die Indizes, das Log und die Notizen. Die Chunks bleiben auf dem Datenträger, bis die Garbage Collection diejenigen löscht, auf die kein Index mehr verweist. Richten Sie für den Datastore mit proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' einen Zeitplan ein. Belegen Sie die Funktion, indem Sie df -h vor und nach proxmox-backup-manager garbage-collection start store1 auf dem Datastore-Pfad ausführen. Rechnen Sie mit einer Verzögerung von mindestens einem Tag, weil Phase zwei nur Chunks entfernt, deren Zugriffszeit älter als 24 Stunden und 5 Minuten ist.

Wie viel Speicherplatz benötigt ein Proxmox Backup Server VPS?

Addieren Sie den tatsächlich von jedem Gast verwendeten Speicherplatz. Addieren Sie anschließend die tägliche Änderung jedes Gasts, multipliziert mit der Anzahl der Tage, für die Sie Backups aufbewahren. Diese Summe ist ein oberer Grenzwert, weil Komprimierung und Deduplizierung zu Ihren Gunsten arbeiten. Planen Sie zusätzlich etwa ein Fünftel für Indizes und Arbeitsbereich ein. Runden Sie anschließend auf eine kaufbare Volume-Größe auf. Prüfen Sie den Wert nach zwei Wochen anhand der tatsächlichen Nutzung in der Datastore-Ansicht erneut. Eine Schätzung vor dem ersten Backup liegt immer in die eine oder andere Richtung falsch.

Wo sollte der Backup-Verschlüsselungsschlüssel gespeichert werden?

Überall, aber nicht ausschließlich auf dem Cluster, das er schützt. Proxmox VE speichert ihn unter /etc/pve/priv/storage/<storage>.enc. Dieser Pfad wird auf jeden Node repliziert und geht daher zusammen mit dem Cluster verloren. Kopieren Sie den Schlüssel am ersten Tag aus dem Cluster. Geben Sie ihn mit proxmox-backup-client key paperkey aus und bewahren Sie diese Kopie in einem anderen Gebäude auf. Beachten Sie außerdem, dass der Schlüssel in den Chunk-Digest einfließt. Wenn Sie ihn später ersetzen, werden beim nächsten Backup daher alle Daten erneut hochgeladen.

Benötige ich einen Datastore pro Proxmox-Host oder Namespaces?

Verwenden Sie einen Datastore und einen Namespace pro Quell-Host oder Cluster. Die Deduplizierung arbeitet innerhalb eines Datastores, nicht zwischen verschiedenen Datastores. Eine Aufteilung nach Hosts speichert daher dieselben Basis-Images mehrfach. Namespaces halten die Backup-Gruppen getrennt. Dadurch können zwei Hosts, die beide einen Gast mit der ID 100 besitzen, nicht kollidieren. Ein Zugriffskontrollpfad der Form /datastore/store1/pve-home beschränkt das API-Token jedes Hosts auf den eigenen Namespace.

Kann ein kleiner VPS als Proxmox-Backup-Server mithalten?

Im Homelab normalerweise ja, weil Chunking und Hashing auf dem Proxmox VE-Node und nicht auf dem Backup-Server stattfinden. Der VPS schreibt die Chunks und führt die beiden rechenintensiven Jobs aus: Garbage Collection und Verifizierung. Geben Sie ihm 4 GB RAM und halten Sie die Anzahl der Verifizierungsthreads niedrig. Planen Sie beide Jobs außerhalb des Backup-Zeitfensters ein. Wenn sie trotzdem deutlich länger dauern, als es der Datenträger erwarten lässt, messen Sie die Steal Time, bevor Sie einen größeren Tarif buchen.