Ransomware adressiert moderne Backup-Systeme als Erstziel. Wer keine Schicht hat, die der Angreifer nach erlangtem Domain-Admin nicht zerstören kann, hat im Vorfall kein brauchbares Backup mehr. Diese Anleitung zeigt unser Standard-Setup für ein wirklich ransomware-resistentes Backup auf Proxmox Backup Server (PBS).
Anwendungsfall: ein 3 – 7-Knoten-Proxmox-VE-Cluster mit 30 – 200 VMs, Recovery-Zeit-Ziel unter 4 Stunden, Aufbewahrung 30 Tage online plus 12 Monate Compliance-Archive.
Architektur-Entscheidungen vor dem Setup
Bevor Sie eine ISO booten, klären Sie diese Fragen — sie bestimmen das Hardware-Sizing:
- Online-Retention: Wie viele Tage sollen sofort verfügbar sein? Standard: 14 – 30 Tage täglich, 12 Wochen wöchentlich, 12 Monate monatlich.
- Air-Gap: Soll es eine wirklich getrennte Schicht geben (zweiter Standort, kein gemeinsames AD, separate Credentials)?
- Compliance-Archiv: Müssen Sie regulatorisch Backups länger als 30 Tage halten? Dann brauchen Sie WORM-Storage (Tape oder S3 Object Lock).
- Restore-Zeit: Der entscheidende Faktor für Hardware-Performance. RTO 30 min braucht NVMe-Pools, RTO 4 h kann mit SAS-SSD.
Hardware-Sizing
Daumenregeln aus echten Deployments:
- CPU: 8 – 32 Cores (Verifikation und ZFS-Replication sind die Hauptverbraucher).
- RAM: 64 – 256 GB (ZFS-ARC + Datastore-Index).
- Storage: netto-Bedarf × 1.4 (für Wachstum) × Replikations-Faktor (typisch 1.0 für lokale RAIDZ2). Bei 80 VMs à 200 GB → 16 TB netto → 22 TB ZFS-Pool, 12-Disk-RAIDZ2 mit 4 TB SAS-SSD funktioniert gut.
- Netzwerk: 25 GbE oder zwei 10-GbE-Bonds zum Cluster, separates Backup-VLAN.
Schritt 1: PBS installieren und Basis-Konfiguration
Boot-Installer von proxmox.com, ZFS-RAIDZ2 als Root-Pool wählen. Nach dem ersten Reboot:
# Repository auf Enterprise (oder no-subscription) setzen
source /etc/os-release
echo 'deb https://enterprise.proxmox.com/debian/pbs '$VERSION_CODENAME' pbs-enterprise' \
> /etc/apt/sources.list.d/pbs-enterprise.list
apt update && apt full-upgrade
# Hostname und Netz
hostnamectl set-hostname pbs-01.intern.example.com
ip a # eth0 mit Backup-VLAN-IP einrichtenSchritt 2: Datastore mit Append-Only-Mode anlegen
Der zentrale Schutz vor Ransomware: ein Datastore, in den ein authentifizierter Client schreiben, aber keine Daten löschen kann.
# ZFS-Pool für Backups (separat vom OS-Pool)
zpool create -o ashift=12 backup-pool raidz2 \
/dev/disk/by-id/scsi-... /dev/disk/by-id/scsi-... \
/dev/disk/by-id/scsi-... ...
zfs set compression=zstd backup-pool
zfs set atime=off backup-pool
zfs create backup-pool/datastore
# Datastore in PBS registrieren
proxmox-backup-manager datastore create prod-daily \
/backup-pool/datastoreIn der Web-UI unter Datastore → prod-daily → Permissions einen API-Token für jeden Cluster anlegen, mit Rolle DatastoreBackup. Wichtig: NICHT die Rolle DatastoreAdmin — die könnte Backups löschen.
Schritt 3: Append-Only via Datastore-Tuning aktivieren
PBS unterstützt zwei komplementäre Schutzmechanismen:
- Datastore-Tuning
append-only-mode: Backups können nur hinzugefügt werden, nicht modifiziert. Wird über die Datastore Tuning-Optionen oder direkt in/etc/proxmox-backup/datastore.cfggesetzt. - Verify-Schedule plus Garbage-Collection-Policy: Verifikation prüft Backup-Integrität täglich; GC läuft nur einmal pro Woche und respektiert Retention-Policies.
# /etc/proxmox-backup/datastore.cfg
datastore: prod-daily
path /backup-pool/datastore
notify-user backup@pbs
tuning append-only=true,verify-new=true
keep-daily 14
keep-weekly 12
keep-monthly 12
# Aktivieren
systemctl reload proxmox-backupSchritt 4: Verifikations-Jobs einrichten
Ein Backup, das nicht regelmäßig auf Integrität geprüft wird, ist Hoffnung. Verifikations-Jobs lesen die Daten zurück und prüfen die Hashes.
# Verify-Job — täglich um 03:00, alle Snapshots der letzten 30 Tage
proxmox-backup-manager verify-job create prod-verify \
--store prod-daily \
--schedule 'daily 03:00' \
--max-depth 3 \
--outdated-after 7dWichtig: Verifikations-Jobs alarmieren bei Fehlern. Die Standard-Notification geht an den im Datastore konfigurierten notify-user per E-Mail. In einem Modern-Next-Setup leiten wir die Mails zusätzlich an einen Wazuh-Agent, der bei Verify-Fehlern einen Slack-/Pager-Alert auslöst.
Schritt 5: ZFS-Snapshots als zweite Sicherungsschicht
Auch wenn Append-Only PBS-seitig konfiguriert ist: ZFS-Snapshots auf dem darunterliegenden Pool sind eine zweite Verteidigungslinie, falls jemand Append-Only umkonfiguriert.
# zfs-auto-snapshot installieren
apt install zfs-auto-snapshot
# Snapshot-Plan definieren
zfs set com.sun:auto-snapshot=true backup-pool/datastore
zfs set com.sun:auto-snapshot:hourly=true backup-pool/datastore
zfs set com.sun:auto-snapshot:daily=true backup-pool/datastore
zfs set com.sun:auto-snapshot:weekly=true backup-pool/datastore
# Restriktion: zfs allow nur explizit notwendige Operationen
zfs unallow -d everyone backup-pool/datastore destroyDamit kann selbst root auf dem PBS-Host die Snapshots der letzten 30 Tage nicht zerstören — die ZFS-Permissions verhindern das. Nur ein Reboot in den Single-User-Mode oder ein manuelles zfs allow-Reset bricht das auf, beides erkennt der SIEM-Agent.
Schritt 6: Offsite-Sync zu zweitem Standort
Lokale Immutability schützt vor Ransomware-Verschlüsselung. Sie schützt nicht vor Brand, Diebstahl oder Hardware-Totalausfall. Daher: PBS-zu-PBS-Replikation an einen zweiten Standort.
# Auf der Quelle (pbs-01)
proxmox-backup-manager remote create offsite \
--host pbs-02.offsite.example.com \
--userid sync@pbs \
--password '...'
# Sync-Job: nächtlich, prod-daily → offsite-mirror
proxmox-backup-manager sync-job create offsite-prod \
--remote offsite \
--remote-store prod-daily \
--store offsite-mirror \
--schedule 'daily 04:30'Wichtig: der Sync-User auf der Quelle hat NUR Lese-Rechte; der Ziel-User hat Write-Append. Damit kann ein kompromittierter Quell-PBS keine Daten am Ziel löschen.
Schritt 7: Restore-Test — der oft vergessene Schritt
Ein Backup-Konzept ohne geübten Restore ist Theorie. Wir machen mit jedem Kunden monatlich einen Restore-Drill: eine zufällig gewählte VM wird in eine isolierte Sub-Cluster-Umgebung wiederhergestellt, gestartet, validiert. Logge die Zeit. Vergleiche mit dem RTO-Ziel.
Standard-Befehl für Live-Restore (VM startet sofort aus dem Backup, während im Hintergrund auf den primären Storage geschoben wird):
# Auf einem Cluster-Node
qm restore <new-vmid> backup://pbs-01/prod-daily/vm/101 --liveRTO bei einer 200-GB-VM aus PBS via 10-GbE: typisch 8 – 15 Minuten bis volle Verfügbarkeit, mit Live-Restore unter 60 Sekunden bis Boot.
Lessons Learned aus echten Setups
- API-Token mit minimalen Rechten — niemals Datastore-Admin-Tokens auf Cluster-Nodes ablegen. Ein kompromittierter Cluster-Node soll Backups schreiben, aber nicht löschen können.
- Notification-Strecke testen — wer nie einen Verify-Fehler simuliert hat, hat keine getestete Alarm-Pipeline. Wir injizieren bewusst kaputte Chunks im Test-Datastore.
- Offsite-Sync-Latenz im Auge behalten — wenn der Sync auf 6 Stunden anwächst, ist Ihr RPO de facto 6 h, nicht der Backup-Plan-RPO.
- Garbage Collection nicht parallel zu Backup-Window laufen lassen — GC ist I/O-intensiv und kann Backup-Jobs ausbremsen.
Fazit
Ein wirklich ransomware-resistentes Backup-Setup ist keine einzelne Konfiguration, sondern eine Schichten-Architektur: Append-Only-Datastore + ZFS-Snapshots + Offsite-Sync + Verifikation + getesteter Restore. Wer eine dieser Schichten weglässt, hat eine Lücke, die im realen Vorfall ausgenutzt wird.
Wir bauen genau dieses Setup bei Modern-Next-Kunden seit 2022. Unsere Backup-Leistung beschreibt das im Kontext einer komplett betreuten Infrastruktur. Für eine Bestandsaufnahme Ihres aktuellen Backup-Konzepts melden Sie sich.
Eigenes Vorhaben in dem Bereich?
30 Minuten reichen für eine ehrliche Einschätzung. Kostenfrei, ohne Vertriebsdruck.