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.

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.

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.

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

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?.