Einen Proxmox-Cluster mit PBS sichern: Deduplizierung, Aufbewahrung und Schutz vor Ransomware

Wer die GAFAM verlässt, um selbst zu hosten, verlässt nicht nur deren Anwendungsdienste, sondern auch deren Infrastruktur für Ausfallsicherheit. Keine unsichtbare Replikation über mehrere Zonen mehr, keine kostenlose Versionierung über 30 Tage, kein Knopf „Stand von vor zwei Wochen wiederherstellen“ mit einem Klick. All das müssen Sie neu aufbauen, und genau das ermöglicht Proxmox Backup Server (PBS), mit einer technischen Qualität, die den kommerziellen Anbietern in nichts nachsteht.

Dieser Artikel nimmt die Architektur von PBS auseinander und nennt die genauen Parameter für eine Backup-Richtlinie, die den drei wichtigsten Katastrophenszenarien standhält: Hardwareausfall, Datenfehler in Anwendungen und Ransomware-Angriff.

Client-Server-Architektur von PBS #

PBS ist kein einfacher periodischer Dump. Es ist ein eigener Server (eine VM oder ein separater physischer Server), der über ein optimiertes Protokoll mit dem Proxmox-Cluster spricht. Der Ablauf: Der PVE-Client zerlegt die Datenträger der VMs in Blöcke fester Größe, berechnet für jeden Block einen Hash und schickt dem PBS-Server nur die Blöcke, die im Datastore noch fehlen. Die Blöcke werden mit Zstandard komprimiert und, wenn der Schlüssel aktiviert ist, auf dem Client verschlüsselt, bevor sie über das Netzwerk gehen.

• Client-Seite (Proxmox VE): proxmox-backup-client, seit PVE 7 nativ in vzdump integriert. Keine zusätzliche Installation.
• Server-Seite (PBS): eigene Debian-Instanz mit einem oder mehreren Datastores auf ZFS oder ext4. Idealerweise auf separater Hardware.
• Protokoll: gemultiplextes HTTP/2 über TLS, Kommunikation authentifiziert per API-Token oder Benutzerzugangsdaten.
• Datastore: strukturiertes Verzeichnis, das die Chunks (deduplizierte Blöcke) und die Indizes pro Snapshot speichert. Das Wachstum bleibt dank globaler Deduplizierung beherrschbar.

Deduplizierung an der Quelle: warum PBS unschlagbar ist #

Deduplizierung ist keine Kompressionsoption: Sie sorgt dafür, dass die Sicherung von 20 ähnlichen Debian-VMs im Datastore so viel Platz belegt wie eine einzige. Konkret liegt die in Produktion beobachtete Deduplizierungsrate in einem typischen Cluster mit 10 Linux-VMs und 3 Windows-VMs zwischen 5× und 12×, das heißt, auf dem PBS-Server liegen 100 GB für etwas, das bei naiver Sicherung 600 GB wären.

Noch besser: Die Deduplizierung gilt für den gesamten Datastore. Eine neue VM, die als Klon einer bestehenden entsteht, belegt beim ersten Backup also fast nichts, nur die Blöcke, die sich seit der Vorlage tatsächlich geändert haben.

Kompression: zstd gegen lzo und gzip #

PBS nutzt seit seiner ersten Version standardmäßig Zstandard. Verglichen mit den von vzdump übernommenen Optionen (lzo, gzip) liegt zstd auf allen drei Achsen gleichzeitig vorn.

Zstandard (zstd) #

• Geschwindigkeit: extrem schnell, mit einem Durchsatz nahe an einer unkomprimierten Datenträgerkopie.
• Multithreading: nativ. Lastet so viele CPU-Kerne aus, wie verfügbar sind.
• Kompressionsrate: hervorragend, besser als lzo, nahe an gzip bei vergleichbarer Stufe.

LZO (veraltet) #

• Geschwindigkeit: mäßig.
• Multithreading: nein.
• Kompressionsrate: niedrig. Nur bei sehr alter Hardware vertretbar.

GZIP (veraltet) #

• Geschwindigkeit: langsam.
• Multithreading: nein.
• Kompressionsrate: hoch, aber die CPU-Kosten ziehen die Backups stark in die Länge.

Mehrstufige Aufbewahrungsrichtlinie #

PBS bietet ein Aufbewahrungsraster mit 5 Stufen, das jede Compliance-Anforderung an die Historie abdeckt, ohne den Speicher volllaufen zu lassen. Die Grundregel: viele aktuelle Snapshots aufbewahren und, je weiter man zurückgeht, immer weniger.

keep-last #

• Aufgabe: unmittelbarer Schutz vor oder nach kritischen Updates.
• Empfohlener Wert: 3 bis 5.
• Abdeckung: einige Stunden bis einige Tage, je nach Backup-Häufigkeit.

keep-daily #

• Aufgabe: tägliches Fenster für eine fein abgestufte Wiederherstellung.
• Empfohlener Wert: 13.
• Abdeckung: zwei volle Wochen, Tag für Tag.

keep-weekly #

• Aufgabe: wöchentliche Historie.
• Empfohlener Wert: 8.
• Abdeckung: zwei Kalendermonate.

keep-monthly #

• Aufgabe: Abdeckung über ein Jahr für Compliance-Anforderungen.
• Empfohlener Wert: 11.
• Abdeckung: ein volles Jahr, Monat für Monat.

keep-yearly #

• Aufgabe: Langzeitarchiv.
• Empfohlener Wert: 9.
• Abdeckung: bis zu 10 Jahre, für gesetzliche Pflichten oder kalte Archivierung.

Löschschutz #

Moderne Ransomware verschlüsselt nicht mehr nur die Produktivdaten: Sie sucht im Netzwerk gezielt nach Backup-Servern, um die Snapshots zu löschen, bevor sie Lösegeld fordert. PBS hat zwei kombinierbare Mechanismen, um dieses Szenario zu verhindern.

Der erste ist die Markierungsdatei .protected in einer Backup-Gruppe: Solange sie existiert, verweigert PBS jedes Löschen von Snapshots dieser Gruppe, auch über die Admin-Oberfläche. Der zweite ist die feine Rechtevergabe pro API-Token: Ein PVE-Client hat nur das Recht Backup, nie das Recht Datastore.Modify.

# Eine Backup-Gruppe vor jedem Löschen schützen
touch /mnt/datastore/backups/vm/100/.protected

# Rechte des vom PVE-Client verwendeten Tokens prüfen
proxmox-backup-manager user list-tokens backup@pbs
# Das Token darf nur die Rolle Datastore.Backup haben

Automatische Prüfung nicht gesicherter VMs #

Das Hauptrisiko einer Backup-Richtlinie ist nicht ein Fehler in der Software, sondern die VM, die an einem Dienstagabend um 23 Uhr angelegt, nie in den Backup-Pool aufgenommen und erst drei Monate später mitten in einer Störung entdeckt wird. Die Proxmox-API bietet einen eigenen Endpunkt für genau diese Prüfung.

# Alle VMs und CTs ohne geplantes Backup auflisten
pvesh get /cluster/backup-info/not-backed-up --output-format json

# Typisches Ergebnis:
# [{"vmid":"105","type":"qemu","name":"web-staging"},
#  {"vmid":"203","type":"lxc","name":"redis-cache"}]

Dieser Befehl läuft in einem täglichen Cronjob, der die JSON-Ausgabe auswertet und die gefundenen Maschinen automatisch einem eigenen Backup-Job namens NewVMs hinzufügt. Keine VM fällt durchs Raster.

#!/bin/bash
# /usr/local/sbin/audit-backups.sh - als täglichen Cronjob einrichten
ORPHANS=$(pvesh get /cluster/backup-info/not-backed-up --output-format json)
COUNT=$(echo "$ORPHANS" | jq 'length')
if [ "$COUNT" -gt 0 ]; then
  echo "$COUNT VM/CT sans sauvegarde detectees" | mail -s "[PVE] Audit backup" admin@exemple.fr
  echo "$ORPHANS" | jq -r '.[].vmid' | while read VMID; do
    pvesh set /cluster/backup/NewVMs --vmid "+$VMID"
  done
fi

Die 3-2-1-Strategie, angewendet auf PBS #

Die universelle Backup-Regel gilt weiterhin: 3 Kopien der Daten, auf 2 verschiedenen Medien, davon 1 außer Haus. Mit PBS sieht das so aus.

• Kopie 1: die Produktivdaten auf den Datenträgern der VMs.
• Kopie 2: der lokale PBS-Datastore auf ZFS mit täglichen Snapshots (erste Verteidigungslinie gegen Datenfehler).
• Kopie 3: ein zweiter, entfernter PBS (VPS bei einem souveränen Hoster), der die Backups jede Nacht per pull über den Sync-Job-Modus von PBS abholt.
• Offline-Bonus: eine verschlüsselte externe USB-Festplatte mit monatlichem Wechsel, physisch offline an einem anderen Ort aufbewahrt. Zu 100 % immun gegen Angriffe über das Netzwerk.

Fazit #

PBS ist kein optionales Modul: Es ist der Baustein, der eine souveräne Infrastruktur wirklich mit den Versprechen der GAFAM vergleichbar macht. Ohne PBS haben Sie eine zerbrechliche private Cloud. Mit PBS haben Sie eine private Cloud, die Ausfälle, Fehler und Angriffe übersteht.

Für ein sauberes Setup brauchen Sie einen Tag, und der rechnet sich beim ersten Vorfall, der immer früher kommt, als man denkt. Wer tiefer in die darunterliegende Infrastruktur einsteigen will: Die Anleitung zur Umstellung von LVM auf ZFS aktiviert die Replikation zwischen Knoten und verbindet so die Ausfallsicherheit durch Backups mit der Ausfallsicherheit durch Redundanz.