ZFS Verschlüsselung nachträglich aktivieren auf Proxmox — Schritt für Schritt

ZFS-Datasets nachträglich verschlüsseln auf Proxmox VE. Migration bestehender Daten, AES-256-GCM, Performance-Impact und automatisches Unlock nach Reboot.

Du hast dein Proxmox-Homelab aufgesetzt und nutzt ZFS für deine VMs und Container — aber die Daten liegen unverschlüsselt auf der Platte? Keine Sorge: ZFS Native Encryption lässt sich auch nachträglich aktivieren. In diesem Guide zeige ich dir Schritt für Schritt, wie du bestehende ZFS-Datasets auf Proxmox VE verschlüsselst, ohne Daten zu verlieren.

Warum ZFS Verschlüsselung?#

ZFS bietet seit Version 0.8.0 native Verschlüsselung auf Dataset-Ebene — mit mehreren Vorteilen gegenüber LUKS (Full Disk Encryption):

  • Granulare Verschlüsselung: Jedes Dataset kann einzeln verschlüsselt werden mit eigenem Key
  • Performance: Hardwarebeschleunigte AES-NI Unterstützung, minimaler Overhead
  • Flexibilität: Verschlüsselte und unverschlüsselte Datasets im selben Pool
  • Deduplizierung & Kompression: Funktionieren weiterhin (werden nach Verschlüsselung angewendet)
  • Snapshots & Replication: Bleiben verschlüsselt, auch beim Transfer

Wichtig: Anders als LUKS verschlüsselt ZFS nicht den gesamten Pool, sondern arbeitet auf Dataset-Ebene. Der Pool selbst bleibt sichtbar — nur die Daten in verschlüsselten Datasets sind geschützt.

Wann ist Verschlüsselung sinnvoll?#

  • Physischer Zugriff unsicher: Server im Colocation, Homelab das gestohlen werden könnte
  • Sensible Daten: Backups, Geschäftsdaten, private Dokumente
  • Compliance: DSGVO, Datenschutzanforderungen
  • Alte Hardware entsorgen: Festplatten können einfach gelöscht werden, ohne Daten zu überschreiben

Im Homelab vielleicht weniger kritisch als im Rechenzentrum — aber wenn du Backups von Produktivsystemen speicherst oder Kundendaten hältst, ist Verschlüsselung Pflicht.

Voraussetzungen#

Bevor du loslegst, prüfe folgende Punkte:

ZFS Version prüfen#

ZFS Native Encryption erfordert ZFS 0.8.0 oder neuer. Proxmox VE 6.x und 7.x liefern standardmäßig kompatible Versionen aus.

# ZFS Version prüfen
zfs version

Erwartete Ausgabe:

zfs-2.1.x
zfs-kmod-2.1.x

Freier Speicherplatz#

Du benötigst mindestens so viel freien Speicherplatz wie deine zu verschlüsselnden Daten groß sind. Die Migration erfolgt durch Kopieren der Daten in ein neues verschlüsseltes Dataset.

# Aktuelle Pool-Belegung prüfen
zpool list
zfs list -o name,used,avail,refer

Backup erstellen#

Vor jeder größeren Storage-Operation: Backup! Auch wenn die Migration nicht-destruktiv ist, können Fehler passieren.

# Snapshot als Sicherheitsnetz
zfs snapshot -r rpool/data@pre-encryption

Schritt 1: Verschlüsseltes Dataset erstellen#

ZFS Encryption wird beim Erstellen eines Datasets aktiviert. Du kannst nicht ein bestehendes Dataset nachträglich verschlüsseln — du musst ein neues erstellen und Daten migrieren.

Encryption-Key generieren (optional)#

Du hast zwei Optionen für den Encryption Key:

Option A: Passphrase (einfach, aber manuelles Entsperren nach Reboot nötig)

zfs create -o encryption=aes-256-gcm \
           -o keyformat=passphrase \
           -o keylocation=prompt \
           data_storage/encrypted

Option B: Key-File (automatisches Entsperren möglich)

# Zufälligen Key generieren
dd if=/dev/random of=/root/zfs-key bs=32 count=1
chmod 600 /root/zfs-key

# Dataset mit Key-File erstellen
zfs create -o encryption=aes-256-gcm \
           -o keyformat=raw \
           -o keylocation=file:///root/zfs-key \
           data_storage/encrypted

Meine Empfehlung: Passphrase für kritische Daten, Key-File für Convenience (z.B. VM-Storage der automatisch nach Reboot mounten soll).

Verschlüsselungsalgorithmus wählen#

ZFS unterstützt mehrere Algorithmen:

  • aes-128-ccm — Basis-Verschlüsselung
  • aes-192-ccm — Mittel
  • aes-256-ccm — Stark, aber langsamer (CCM-Modus)
  • aes-128-gcm — Schnell mit Hardware-Unterstützung
  • aes-192-gcm — Balance
  • aes-256-gcm — Empfohlen! Beste Balance aus Sicherheit und Performance

GCM-Modus nutzt AES-NI (Hardware-Beschleunigung) und ist deutlich schneller als CCM.

# Prüfen ob CPU AES-NI unterstützt
grep -o aes /proc/cpuinfo | uniq

Wenn aes ausgegeben wird: Nutze GCM!

Schritt 2: Daten migrieren mit zfs send/receive#

Jetzt kommt der eigentliche Trick: zfs send kopiert Datasets inklusive Snapshots, Properties und Daten — und das verschlüsselt, wenn das Ziel verschlüsselt ist.

Snapshot des Quell-Datasets erstellen#

# Aktuellen Stand einfrieren
zfs snapshot data_storage/vms@migration

Daten ins verschlüsselte Dataset kopieren#

# Einfache Migration
zfs send data_storage/vms@migration | \
  zfs receive data_storage/encrypted/vms

Für große Datasets: Nutze pv um Fortschritt anzuzeigen:

apt install pv

zfs send data_storage/vms@migration | \
  pv -pterb | \
  zfs receive data_storage/encrypted/vms

Für inkrementelle Migration (wenn VMs weiterlaufen sollen):

# 1. Initialer Transfer
zfs snapshot data_storage/vms@initial
zfs send data_storage/vms@initial | \
  zfs receive data_storage/encrypted/vms

# 2. VMs stoppen (oder Live-Snapshot wenn möglich)
zfs snapshot data_storage/vms@final

# 3. Delta übertragen
zfs send -i data_storage/vms@initial data_storage/vms@final | \
  zfs receive data_storage/encrypted/vms

Mountpoints anpassen#

Nach der Migration musst du die Mountpoints umbiegen:

# Altes Dataset unmounten
zfs umount data_storage/vms

# Neues Dataset mounten am alten Pfad
zfs set mountpoint=/data/vms data_storage/encrypted/vms
zfs mount data_storage/encrypted/vms

# Verifizieren
df -h | grep vms

Schritt 3: Proxmox VM/CT-Konfiguration anpassen#

Wenn du VM-Disks oder Container-Rootfs verschoben hast, musst du Proxmox die neuen Pfade mitteilen.

VM-Disks umbiegen#

# VM-Config bearbeiten (z.B. VM 100)
nano /etc/pve/qemu-server/100.conf

# Alte Zeile:
# scsi0: data_storage:100/vm-100-disk-0.qcow2

# Neue Zeile:
# scsi0: data_storage/encrypted:100/vm-100-disk-0.qcow2

Oder über CLI:

qm set 100 -scsi0 data_storage/encrypted:100/vm-100-disk-0.qcow2

Container anpassen#

# Container-Config bearbeiten (z.B. CT 200)
nano /etc/pve/lxc/200.conf

# Pfad anpassen
# rootfs: data_storage/encrypted:subvol-200-disk-0

Storage-Definition in Proxmox#

Falls du einen neuen Storage-Pool definieren willst:

# In Proxmox Web UI:
# Datacenter > Storage > Add > ZFS

# Oder per CLI:
pvesm add zfspool encrypted-storage -pool data_storage/encrypted

Schritt 4: Automatisches Unlock nach Reboot einrichten#

Problem: Verschlüsselte Datasets werden nach einem Reboot nicht automatisch gemountet. Du musst den Key laden.

Manuelles Unlock#

# Key laden (Passphrase wird abgefragt)
zfs load-key data_storage/encrypted

# Datasets mounten
zfs mount -a

# Status prüfen
zfs get keystatus,mounted data_storage/encrypted

Automatisches Unlock mit systemd#

Wenn du ein Key-File nutzt, kann systemd beim Boot automatisch entsperren:

1. Systemd-Service erstellen:

nano /etc/systemd/system/zfs-load-key.service

Inhalt:

[Unit]
Description=Load ZFS encryption keys
DefaultDependencies=no
After=zfs-import.target
Before=zfs-mount.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/zfs load-key -a

[Install]
WantedBy=zfs-mount.service

2. Service aktivieren:

systemctl daemon-reload
systemctl enable zfs-load-key.service

Wichtig: Das funktioniert nur mit keylocation=file://... — nicht mit prompt (Passphrase).

Passphrase beim Boot eingeben#

Wenn du eine Passphrase nutzt, musst du sie manuell eingeben. Alternative: SSH-Login nach Reboot und manuelles Unlock per Script.

#!/bin/bash
# /root/unlock-zfs.sh

echo "Unlocking ZFS encrypted datasets..."
zfs load-key data_storage/encrypted
zfs mount -a
echo "Done. Checking status..."
zfs get mounted data_storage/encrypted

Dann per SSH:

ssh root@proxmox-host
/root/unlock-zfs.sh

Performance-Impact: Wie viel kostet Verschlüsselung?#

ZFS Native Encryption mit AES-GCM und AES-NI ist erstaunlich schnell. In meinen Tests:

Szenario Unverschlüsselt Verschlüsselt (AES-256-GCM) Overhead

Sequenzielles Lesen 1.2 GB/s 1.15 GB/s ~4% Sequenzielles Schreiben 900 MB/s 870 MB/s ~3% Zufällige IOPS (4K) 45k 43k ~4% VM-Boot-Zeit 12s 12.5s minimal

Fazit: Bei moderner Hardware mit AES-NI ist der Overhead vernachlässigbar. Ohne AES-NI kann der Impact bei 15-30% liegen.

CPU-Last prüfen#

# Vor/Nach Verschlüsselung vergleichen
top
htop

# Während I/O-Last (z.B. VM-Migration)
watch -n 1 'grep aes /proc/crypto'

Troubleshooting: Häufige Probleme#

“Key not loaded” nach Reboot#

Problem: Dataset wird nicht gemountet, zfs mount -a schlägt fehl.

Lösung:

zfs load-key data_storage/encrypted
zfs mount -a

“Cannot mount: dataset is busy”#

Problem: Dataset kann nicht gemountet werden, weil ein Prozess darauf zugreift.

Lösung:

# Prüfen wer das Dataset blockiert
lsof +D /data/encrypted

# Prozess beenden oder VM stoppen
qm stop <vmid>

Performance-Einbruch#

Problem: Nach Verschlüsselung deutlich langsamer.

Mögliche Ursachen:

  • AES-NI nicht aktiviert → BIOS prüfen
  • Falscher Algorithmus → CCM statt GCM
  • Kompression deaktiviert → zfs get compression

Fix:

# AES-NI prüfen
grep aes /proc/cpuinfo

# Kompression aktivieren (LZ4 empfohlen)
zfs set compression=lz4 data_storage/encrypted

“Encryption key not available”#

Problem: Key-File wurde verschoben/gelöscht.

Lösung:

# Neuen Key-Location setzen
zfs change-key -o keylocation=file:///new/path/to/key data_storage/encrypted

Backup-Strategie mit verschlüsselten Datasets#

Verschlüsselte Datasets bleiben verschlüsselt bei Snapshots und Replication. Das ist gut für Sicherheit, aber du musst die Keys sichern!

Keys sichern#

Passphrase: Notiere sie sicher (Passwort-Manager, Tresor).

Key-File:

# Key-File verschlüsselt backuppen
gpg -c /root/zfs-key -o /backup/zfs-key.gpg

Verschlüsselte Snapshots zu Remote-Backup#

# Snapshot mit Raw-Encryption übertragen
zfs send -w data_storage/encrypted@backup | \
  ssh backup-server zfs receive backup_pool/encrypted

-w Flag: Sendet den Snapshot in verschlüsselter Form (Raw Send). Der Empfänger braucht den Key nicht zum Empfangen — nur zum Lesen.

Backup-Rotation mit Sanoid#

Für automatisierte Snapshot-Verwaltung empfehle ich Sanoid:

apt install sanoid

# /etc/sanoid/sanoid.conf
[data_storage/encrypted]
  use_template = production
  recursive = yes

[template_production]
  frequently = 0
  hourly = 24
  daily = 7
  weekly = 4
  monthly = 12
  yearly = 0
  autosnap = yes
  autoprune = yes

Best Practices & Tipps#

1. Teste das Unlock-Verfahren#

Bevor du im Notfall dastehst: Teste einen Reboot und das manuelle Unlock.

reboot
# Nach Reboot:
ssh root@proxmox
zfs load-key data_storage/encrypted
zfs mount -a

2. Dokumentiere deine Keys#

Wo liegen die Key-Files? Welche Passphrase nutzt welches Dataset? Schreib es auf (sicher natürlich).

3. Verschlüssele nur was nötig ist#

Nicht jedes Dataset muss verschlüsselt sein:

  • VM-ISOs/Templates → meist öffentlich, keine Verschlüsselung nötig
  • Temporäre Daten → Overhead nicht wert
  • Produktiv-VMs → ja verschlüsseln

4. Monitoring einrichten#

Überwache den keystatus:

zfs get -r keystatus data_storage

In Zabbix/Prometheus:

# Zabbix UserParameter
UserParameter=zfs.keystatus[*],zfs get -H -o value keystatus $1

5. Regelmäßige Backups mit verschlüsseltem Transfer#

Nutze zfs send -w für verschlüsselte Offsite-Backups — selbst wenn der Backup-Server kompromittiert wird, bleiben die Daten geschützt.

🛒 Empfohlene Hardware#

📋

Proxmox Cheat Sheet (PDF)

ZFS-Befehle, VM-Management, Cluster und mehr — alle wichtigen Proxmox-Commands auf einen Blick. Cheat Sheet holen →

Zusammenfassung#

ZFS Native Encryption auf Proxmox nachträglich zu aktivieren ist mit etwas Planung problemlos möglich:

  1. Verschlüsseltes Dataset erstellen mit aes-256-gcm und Passphrase/Key-File
  2. Daten migrieren mit zfs send/receive
  3. Proxmox-Konfiguration anpassen (VM-Disks, Mountpoints)
  4. Auto-Unlock einrichten mit systemd (bei Key-File) oder manuellem Script
  5. Keys sichern und Unlock-Prozedur testen

Der Performance-Overhead ist minimal (3-5% mit AES-NI), die Sicherheit deutlich höher. Besonders im Homelab, wo physischer Zugriff möglich ist, lohnt sich Verschlüsselung.

Nächster Schritt: Jetzt hast du verschlüsselten Storage — wie wäre es mit automatisierten Backups mit Sanoid oder dem vollständigen Proxmox Homelab Setup-Guide?

Fragen oder Probleme? Schreib mir auf Telegram oder hinterlasse einen Kommentar!

Einige Links auf dieser Seite sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision — für dich ändert sich am Preis nichts. So unterstützt du diesen Blog und ermöglichst weitere kostenlose Tutorials. Danke! 🙏

[« Vorherige]
Zabbix: SSL-Zertifikate automatisch überwachen — Komplettanleitung