Proxmox Backup Server einrichten: Anleitung von Grund auf

Proxmox VE bringt eine eingebaute Backup-Funktion mit, die vollständige Abbilder als vzdump-Archive wegschreibt. Das funktioniert – ist aber genau das, was man nicht will, sobald die Umgebung wächst: Jede Sicherung schreibt die kompletten Daten erneut, der Platzbedarf wächst linear, und ein Backup dauert so lange, wie die VM groß ist.

Proxmox Backup Server (PBS) löst das über Deduplizierung auf Chunk-Ebene. Nach dem ersten vollständigen Lauf überträgt jede weitere Sicherung nur noch geänderte Blöcke. Dieser Artikel zeigt die Einrichtung von der Installation bis zum ersten geprüften Restore-Punkt.

Er gehört zum Cluster rund um die 3-2-1-Backup-Strategie und deckt darin die lokale zweite Kopie ab. Die Kopie außer Haus folgt in Offsite-Backup.

Warum ein eigener Server statt eines Verzeichnisses

Die berechtigte Frage vorweg: Warum eine zusätzliche Maschine, wenn man auch auf ein NFS-Share sichern kann?

Deduplizierung. PBS zerlegt Daten in Chunks und speichert jeden Chunk genau einmal. Zehn ähnliche Linux-VMs belegen dadurch deutlich weniger als die Summe ihrer Größen. Bei täglichen Sicherungen über Wochen ist der Unterschied nicht graduell, sondern kategorisch.

Inkrementell ohne Vollsicherung. Nach dem ersten Lauf werden nur geänderte Blöcke übertragen. Ein Backup, das mit vzdump eine Stunde dauert, ist danach oft in Minuten durch.

Verifikation. PBS kann gespeicherte Chunks gegen ihre Prüfsummen validieren – und findet damit stille Beschädigung, bevor du sie im Ernstfall entdeckst.

Trennung. Ein eigenes System bedeutet: Wer den Hypervisor kompromittiert, hat noch keinen Zugriff auf die Sicherungen. Das ist der Punkt, an dem PBS gegenüber einem gemounteten Share einen echten Sicherheitsvorteil hat – siehe Ransomware-sichere Backups.

Der Preis: eine weitere Maschine, die gewartet werden muss. Für ein Homelab mit zwei VMs lohnt sich das nicht. Ab etwa fünf VMs oder sobald Container mit veränderlichen Daten dazukommen, dreht sich die Rechnung deutlich.

Wohin mit dem PBS?

Drei Varianten, mit klarem Ranking:

Variante	Bewertung
Eigene physische Maschine	Beste Wahl. Überlebt den Ausfall des Hypervisors. Ein sparsamer Mini-PC mit ausreichend Plattenplatz genügt.
VM auf einem anderen Host	Vertretbar, wenn ein zweiter Host existiert.
VM auf demselben Host	Nur als Übergangslösung. Stirbt der Host, sind Produktivsystem und Sicherung gleichzeitig weg – das verletzt die 3-2-1-Regel im Kern.

Was PBS tatsächlich braucht

Die verbreitete Annahme lautet: Ein Sicherungsserver braucht eine kräftige Maschine. Das Dashboard derselben Instanz, aus der die Screenshots dieses Artikels stammen, sagt etwas anderes.

Größe	Zugewiesen	Tatsächlich belegt
Arbeitsspeicher	8,00 GiB	72,63 MiB
Systemdatenträger	16,11 GB	2,86 GB
Prozessor	4 Kerne	20,22 % zum Zeitpunkt der Aufnahme

Die erste Zeile ist die überraschende: PBS belegt im Leerlauf nicht einmal ein Prozent des zugewiesenen Arbeitsspeichers. Der Grund liegt in der Bauweise – die Deduplizierung arbeitet über Prüfsummen auf der Platte und nicht über eine Tabelle im Arbeitsspeicher. PBS ist in dieser Hinsicht kein ZFS.

Genau darin liegt aber auch die Einschränkung: Sobald der Datastore selbst auf ZFS liegt, gilt die Zahl nicht mehr. Dann kommt der ARC dazu, und der Speicherbedarf richtet sich nach der Poolgröße statt nach PBS. Wer auf ext4 oder XFS bleibt, kommt mit wenigen Gigabyte aus.

Der Systemdatenträger ist ähnlich genügsam: 16 GB sind reichlich bemessen, gut zwei davon belegt. Der Platz, auf den es ankommt, ist der des Datastores – und der ist eine eigene Entscheidung, siehe unten.

Was das für den Einkauf heißt: Der Engpass sind die Platten, nicht die Rechenkraft. Im selben Moment, in dem der Prozessor zu einem Fünftel ausgelastet war, lag die IO-Verzögerung bei 10,25 % und die Systemlast bei knapp 20 – auf vier Kernen. Es warten also Vorgänge auf die Platte, nicht auf Rechenzeit. Das ist eine Momentaufnahme und kein Dauerwert, deckt sich aber mit dem, was PBS die meiste Zeit tut: lesen, prüfen, schreiben.

Für einen sparsamen Mini-PC als Sicherungsziel spricht damit alles. Geld gehört in Kapazität und in ordentliche Datenträger, nicht in Kerne.

Installation

Zwei Wege führen zum Ziel.

Weg 1 – ISO-Installer. Das offizielle PBS-ISO herunterladen, davon booten, Installer durchlaufen. Bringt ein fertiges Debian mit vorkonfiguriertem PBS. Der einfachere Weg, empfehlenswert für eine dedizierte Maschine.

Weg 2 – auf bestehendem Debian. Wenn die Maschine schon läuft, lässt sich PBS aus dem Proxmox-Repository nachinstallieren:

# Repository-Schlüssel und Paketquelle eintragen
# (aktuelle Pfade in der offiziellen Doku prüfen – sie ändern sich
#  zwischen Debian-Releases)
apt update
apt install proxmox-backup-server

Danach ist die Oberfläche erreichbar unter:

https://<ip-des-servers>:8007

Anmeldung als root gegen das Realm PAM – also mit dem Systempasswort der Maschine.

Das Zertifikat ist selbstsigniert, der Browser warnt entsprechend. Für den Anfang akzeptieren. Falls du intern eine eigene CA oder Let’s Encrypt betreibst, lässt sich das Zertifikat später unter Configuration → Certificates austauschen.

Nach der Anmeldung steht das Dashboard mit Auslastung, Version und den vorhandenen Datastores:

Der Hinweis Non production-ready repository enabled stammt vom Community-Repository ohne Subskription. Er ist kein Fehler und für den privaten Einsatz unbedenklich – er weist nur darauf hin, dass diese Paketquelle keine Enterprise-Tests durchlaufen hat.

Datastore anlegen

Der Datastore ist der Speicherort für die Chunks. Ohne ihn kann PBS nichts entgegennehmen.

Vorher die Platten einbinden. PBS bringt unter Administration → Storage/Disks eine Oberfläche mit, über die sich ZFS-Pools, Verzeichnisse oder LVM anlegen lassen.

Zur Dateisystemwahl: ZFS ist hier die naheliegende Wahl, weil es Prüfsummen über alle Daten bildet und damit stille Beschädigung erkennt – genau das, was ein Backup-Speicher leisten muss. Der Preis ist Arbeitsspeicher. Wenn der knapp ist, tut es auch ein ext4- oder XFS-Verzeichnis; dann übernimmt allein die PBS-Verifikation die Integritätsprüfung.

Anschließend Datastore → Add Datastore:

• Name – erscheint später in PVE als Teil des Speicherpfads
• Backing Path – der Pfad im Dateisystem, z. B. /mnt/datastore/backup
• Prune-Optionen – lassen sich hier direkt setzen, siehe unten

Nach dem Anlegen erzeugt PBS die Verzeichnisstruktur für den Chunk-Store. Das kann bei großen Dateisystemen einen Moment dauern.

Was die Deduplizierung tatsächlich bringt

Der Zahlenwert, nach dem beim Planen zuerst gesucht wird, steht unter Datastore → Summary. Aus der Umgebung, aus der die Screenshots dieses Artikels stammen:

	backup-local	backup-nfs
Belegt	1,39 TB von 1,50 TB	1,46 TB von 8,76 TB
Deduplizierungsfaktor	11,48	12,97
Voraussichtlich voll	in 1 Jahr 20 Tagen	in 3 Jahren 166 Tagen

Ein Faktor von 11,5 heißt: Was PBS an Sicherungen vorhält, entspräche unkomprimiert und ohne Deduplizierung etwa dem Elffachen des tatsächlich belegten Platzes. Genau dieser Effekt macht tägliche Vollsicherungen über Monate hinweg überhaupt bezahlbar.

Ein Wort zur Einordnung: Der Faktor hängt fast vollständig davon ab, was gesichert wird und wie lange es aufbewahrt wird. Viele ähnliche VMs mit demselben Betriebssystem und eine lange Aufbewahrung treiben ihn nach oben; wenige, stark unterschiedliche Gäste mit kurzer Aufbewahrung drücken ihn in Richtung 2 bis 4. Zahlen aus fremden Umgebungen – auch die obigen – taugen daher zur Größenordnung, nicht zur Kapazitätsplanung. Dafür hilft nur der eigene Wert nach einigen Wochen Betrieb.

Was auf diesem Bild sonst noch steht

Die Aufgabenstatistik rechts ist der Grund, warum sich der Blick auf diese Seite lohnt. 288 erfolgreiche Sicherungen bei 2 Fehlern sind unauffällig. Drei andere Angaben sind es nicht:

3 erfolgreiche gegen 4 fehlgeschlagene Sync-Jobs. Die Kopie außer Haus kommt also häufiger nicht an als an. Wer nur auf die Backup-Zeile schaut, hält diesen Datastore für gesund.

2 fehlgeschlagene Verify-Läufe. Das ist die ernsteste Meldung auf der ganzen Seite. Verify prüft gespeicherte Chunks gegen ihre Prüfsummen; ein Fehlschlag heißt, dass bereits abgelegte Daten nicht mehr lesbar sind. Zwei davon unter 291 Läufen sind keine Fußnote, sondern eine Arbeitsanweisung: nachsehen, welcher Sicherungsstand betroffen ist, und ihn neu erzeugen. Ein Bestand mit stillen Lesefehlern ist gefährlicher als ein offensichtlich fehlender – weil man sich auf ihn verlässt.

93 % Füllstand. Die Prognose „voll in 1 Jahr 20 Tagen“ klingt beruhigend und ist es nicht: Sie schreibt bloß das bisherige Wachstum fort. Ein einziger neuer Gast oder eine verlängerte Aufbewahrung verkürzt sie auf Wochen. Ab etwa 85 % gehört Platz beschafft, nicht beobachtet.

Dass diese drei Punkte hier stehen und nicht aus dem Bild entfernt wurden, ist Absicht: So sieht ein tatsächlich betriebener Datastore aus. Und genau darin liegt die Lehre – keiner der drei Befunde meldet sich von selbst. Man findet sie nur, wenn man diese Seite aufruft. Damit das nicht nötig ist, gibt es Backups überwachen.

Zugang für Proxmox VE einrichten

Jetzt der Teil, den viele überspringen und später bereuen: PVE bekommt keinen root-Zugang.

Der Grund ist derselbe wie im gesamten Cluster: Wird der Hypervisor kompromittiert, soll der Angreifer die Sicherungen nicht löschen können. Ein eigener Benutzer mit minimalen Rechten kostet fünf Minuten und ist der wirksamste Einzelschritt dieser Anleitung.

1. Benutzer anlegen – Configuration → Access Control → User Add, z. B. pve-backup@pbs.

2. Berechtigung vergeben – Permissions → Add → Datastore Permission:

Rolle	Was sie erlaubt	Wofür
DatastoreBackup	Sicherungen anlegen und lesen	der Normalfall
DatastoreReader	nur lesen	für reine Restore-Zugänge
DatastorePowerUser	zusätzlich eigene Sicherungen löschen	nur wenn wirklich nötig
DatastoreAdmin	alles	nicht für den PVE-Zugang

Für die produktive Sicherung ist DatastoreBackup richtig. Das Löschen alter Stände übernimmt der Prune-Job auf dem PBS selbst – nicht der Client.

3. API-Token statt Passwort. Unter API Tokens ein Token für den Benutzer anlegen. Der Geheimwert wird genau einmal angezeigt. Notieren, sonst neu erzeugen. Das Token braucht dieselbe Datastore-Berechtigung wie der Benutzer – und genau daran scheitert die Einrichtung am häufigsten: Token angelegt, Berechtigung vergessen, beim ersten Backup kommt „permission denied“.

4. Fingerprint notieren. Unter Dashboard → Show Fingerprint den SHA-256-Fingerprint kopieren. PVE braucht ihn, um dem selbstsignierten Zertifikat zu vertrauen.

Einbinden in Proxmox VE

In der PVE-Oberfläche: Datacenter → Storage → Add → Proxmox Backup Server.

Feld	Wert
ID	frei wählbarer Name, z. B. pbs
Server	IP oder Hostname des PBS
Username	pve-backup@pbs!<tokenname>
Password	der Token-Geheimwert
Datastore	Name des Datastores
Fingerprint	der kopierte SHA-256-Wert

Die Schreibweise des Benutzernamens ist der zweite klassische Stolperstein: Bei Token-Authentifizierung gehören Benutzer und Tokenname in dasselbe Feld, getrennt durch ein Rufzeichen.

Nach dem Speichern zeigt PVE die Kapazität des Datastores an. Passiert das nicht, stimmt eine der fünf Angaben nicht – am wahrscheinlichsten Fingerprint oder Token-Berechtigung.

Verschlüsselung

Beim Einrichten des Speichers lässt sich ein Verschlüsselungsschlüssel erzeugen. Die Verschlüsselung findet dann auf dem PVE statt, bevor die Daten den Host verlassen. Der PBS speichert nur noch unlesbare Chunks.

Das ist sinnvoll, sobald der PBS nicht vollständig unter deiner Kontrolle steht – und Pflicht, wenn die Daten später zu einem Anbieter repliziert werden.

Und es ist der gefährlichste Schritt dieser Anleitung. Ohne Schlüssel ist kein Restore möglich. Der Schlüssel muss an einem Ort liegen, den du auch dann erreichst, wenn genau der Host weg ist, auf dem er erzeugt wurde. Verfahren dafür: Backup-Verschlüsselung.

Backup-Job einrichten

Datacenter → Backup → Add:

• Storage – der eben angelegte PBS-Speicher
• Schedule – Zeitplan; die Syntax orientiert sich an systemd-Timern, 02:30 bedeutet täglich halb drei
• Selection Mode – „All“ sichert auch VMs, die es heute noch nicht gibt. Für Homelabs meist die richtige Wahl, weil nichts vergessen wird.
• Mode – siehe unten
• Notification – nicht überspringen, siehe Backup-Monitoring

Zwei Felder in diesem Dialog verdienen mehr Aufmerksamkeit, als ihre Größe vermuten lässt.

Selection mode. Die Voreinstellung Include selected VMs verlangt, dass jede neue VM von Hand in den Job aufgenommen wird. Das geht so lange gut, bis es das erste Mal vergessen wird – und bemerkt wird es erst, wenn die Sicherung gebraucht wird. All nimmt automatisch alles mit, auch Gäste, die es heute noch nicht gibt. Für Homelabs und kleine Umgebungen ist das fast immer die richtige Wahl. Wer gezielt ausschließen will, nimmt Exclude selected VMs – dann ist die Voreinstellung „gesichert“ statt „vergessen“.

Compression. ZSTD ist der Standard und bleibt es. Der Hinweis „fast and good“ ist ausnahmsweise keine Werbung: ZSTD komprimiert schneller als GZIP und dabei besser als LZO. Beim Sichern auf einen PBS ist die Einstellung ohnehin nachrangig, weil dort ohnehin dedupliziert und komprimiert wird.

Aufbewahrung, Benachrichtigung und der Rest

Die übrigen Reiter des Dialogs sind schnell erklärt:

• Retention – wie lange die Stände dieses Jobs vorgehalten werden. Bleibt das Formular leer, gilt die Einstellung des Speichers. Was dort sinnvollerweise hineingehört, steht in Aufbewahrung planen.
• Notifications – standardmäßig gelten die globalen Einstellungen des Rechenzentrums. Warum das nicht reicht, steht in Backups überwachen.
• Note Template – beschriftet jeden Sicherungsstand automatisch. Mit {{guestname}} - {{node}} steht später in der Übersicht, was der Stand enthält, statt nur einer VM-Nummer. Kostet einmal 30 Sekunden und spart bei jedem Restore das Nachschlagen.

Der Reiter Advanced kann in aller Regel unangetastet bleiben. Zwei Optionen sind trotzdem erwähnenswert:

• Bandwidth Limit – begrenzt die Schreibrate. Sinnvoll, wenn die Sicherung über eine Leitung läuft, die tagsüber gebraucht wird.
• Repeat missed – holt einen Lauf nach, der ausgefallen ist, weil der Knoten zum geplanten Zeitpunkt nicht lief. Ohne diese Option fällt die Sicherung dieses Tages ersatzlos aus, und der Job meldet dafür keinen Fehler – er wurde ja nie gestartet.

Snapshot, Suspend oder Stop?

Modus	Verhalten	Wann
Snapshot	VM läuft weiter, Sicherung aus einem Snapshot	Standard für fast alles
Suspend	VM wird kurz angehalten	wenn Snapshot nicht möglich ist
Stop	VM wird heruntergefahren	wenn absolute Konsistenz nötig ist

Zum Snapshot-Modus gehört eine wichtige Einschränkung: Er sichert den Zustand der virtuellen Platte, nicht den Zustand der Anwendung darin. Eine Datenbank, die gerade mitten in einer Transaktion steckt, wird in genau diesem Zustand eingefroren.

Für Linux-Gäste installiert man deshalb den QEMU Guest Agent und aktiviert in den VM-Optionen QEMU Guest Agent → Enabled samt Dateisystem-Freeze. Der Agent friert vor dem Snapshot die Dateisysteme kurz ein und sorgt so für einen sauberen Stand.

Für Datenbanken gilt trotzdem: Ein VM-Snapshot ersetzt keinen Datenbank-Dump. Beides machen.

Verify, Prune und Garbage Collection

Drei Jobs, die oft verwechselt werden. Ohne sie läuft der Datastore entweder voll oder liefert unbemerkt kaputte Daten.

Verify prüft gespeicherte Chunks gegen ihre Prüfsummen und findet stille Beschädigung. Einrichten unter Datastore → Verify Jobs. Sinnvoll ist wöchentlich, mit der Option, bereits verifizierte Sicherungen für einige Tage zu überspringen – sonst wird bei jedem Lauf der komplette Bestand gelesen.

Prune entfernt nicht mehr benötigte Sicherungsstände nach Regeln. Es gibt dabei noch keinen Speicher frei – es markiert nur, was wegdarf.

Beispiel für eine tägliche Sicherung:

  keep-daily    7      die letzte Woche taggenau
  keep-weekly   4      der letzte Monat wochenweise
  keep-monthly  6      das letzte halbe Jahr monatlich

Die Herleitung solcher Werte – und warum sie von der Aufbewahrungsfrist und nicht vom Bauchgefühl abhängen – steht in Backup-Aufbewahrung planen.

Garbage Collection gibt den Speicher tatsächlich frei, indem sie Chunks löscht, auf die kein Sicherungsstand mehr verweist. Ohne GC bringt Prune kein einziges Byte zurück. GC läuft in zwei Phasen und braucht Zeit; sie sollte planmäßig laufen, meist wöchentlich nach dem Prune-Job.

Die häufigste Verwirrung in diesem Bereich: „Ich habe alte Backups gelöscht, aber der Speicher ist immer noch voll.“ Antwort: GC lief noch nicht.

Der erste Restore – jetzt, nicht später

Ein Backup-Setup ist nicht fertig, wenn der erste Job grün ist. Es ist fertig, wenn ein Restore funktioniert hat.

Der schnellste Nachweis: In PVE unter Backup einen Sicherungsstand auswählen, Restore, und als Ziel eine neue VM-ID angeben. Damit wird nichts überschrieben, und du siehst, ob die wiederhergestellte Maschine bootet.

Für einzelne Dateien bietet PBS File Restore: Ein Sicherungsstand wird durchsucht, ohne die ganze VM zurückzuspielen. Für den häufigsten aller Ernstfälle – eine gelöschte Datei – ist das der Weg.

Wie daraus ein wiederholbares, dokumentiertes Verfahren wird, steht in Restore testen.

Häufige Fehler bei der Einrichtung

Symptom	Ursache
„permission denied“ beim ersten Backup	Token angelegt, aber keine Datastore-Berechtigung vergeben
Verbindung schlägt fehl, Zertifikatsfehler	Fingerprint falsch kopiert oder nach Zertifikatswechsel veraltet
Speicher wird trotz Prune nicht frei	Garbage Collection läuft nicht
Erstes Backup extrem langsam	normal – erst der zweite Lauf ist inkrementell
Datenbank-VM inkonsistent zurückgespielt	Guest Agent fehlt, oder Dump wurde nicht zusätzlich gemacht
Restore auf anderem Host schlägt fehl	Verschlüsselungsschlüssel liegt nur auf dem Ursprungshost

Zusammenfassung

1. PBS installieren, Oberfläche auf Port 8007 erreichbar
2. Datastore anlegen – ZFS, wenn der Arbeitsspeicher es zulässt
3. Eigenen Benutzer mit DatastoreBackup und API-Token anlegen
4. Fingerprint notieren, Speicher in PVE einbinden
5. Verschlüsselung entscheiden – Schlüssel sofort extern sichern
6. Backup-Job mit Snapshot-Modus und Guest Agent
7. Verify-, Prune- und GC-Jobs einrichten
8. Restore testen, bevor du das Setup für fertig erklärst

Damit steht die zweite Kopie der 3-2-1-Strategie. Als Nächstes folgt die Kopie außer Haus: Offsite-Backup.

Wenn du noch unsicher bist, ob PBS überhaupt das richtige Werkzeug ist – für reine Dateisicherung ohne Virtualisierung ist es das oft nicht. Der Vergleich steht in restic, Borg oder PBS?.