TrueNAS-Replikation mit ZFS-Encryption-Keys richtig handhaben

ZFS-Native-Encryption ist in TrueNAS seit Jahren produktiv — spätestens mit SCALE 25.10 (Codename “Goldeye”) ist sie für viele unserer Kunden Standard auf dem primären Storage. Sobald jedoch eine Replication-Task hinzukommt, häufen sich die Fragen: Werden die Daten verschlüsselt übertragen? Liegt der Key auch auf dem Zweitsystem? Und wer kommt im Ernstfall noch an die Daten ran, wenn die Management-Station ausfällt?

Dieser Beitrag räumt mit den häufigsten Missverständnissen auf und zeigt ein Setup, das wir in mehreren Häusern produktiv betreiben — inklusive der Schritte, die im Recovery-Fall wirklich gebraucht werden.

Raw Send: warum Sie ihn fast immer wollen

ZFS kennt zwei Wege, ein verschlüsseltes Dataset zu replizieren. Beim klassischen zfs send wird das Dataset auf der Quelle entschlüsselt, der Klartext wandert in den Send-Stream und wird am Ziel mit dem dortigen Encryption-Root neu verschlüsselt (oder gar nicht). Beim Raw Send — in TrueNAS heißt die Option schlicht “Encryption” in der Replication-Task und entspricht zfs send --raw — bleibt das Dataset von Anfang bis Ende verschlüsselt. Die Quelle muss den Key gar nicht laden, das Ziel speichert die Blöcke so, wie sie auf der Platte lagen.

Für nahezu alle SMB-Backup-Szenarien ist Raw Send der richtige Weg:

• Der Key verlässt das Primärsystem nie über die Replikationsleitung.
• Ein kompromittiertes Zweitsystem oder ein gestohlener Backup-Server gibt keine Klartextdaten preis.
• Die Replication-Verbindung muss nicht zwingend zusätzlich TLS-verschlüsselt sein — TrueNAS macht das per SSH ohnehin, aber selbst ein passiver Lauscher hätte nichts gewonnen.
• Snapshots, Properties und die komplette Key-Hierarchie bleiben 1:1 erhalten.

Der Preis: Auf dem Zweitsystem ist das Dataset ohne Key zunächst nicht lesbar. Genau das ist aber meistens auch das, was Sie wollen.

Setup in TrueNAS SCALE 25.10 — Schritt für Schritt

Wir nehmen ein typisches Setup: Primär-NAS nas01 in Neuburg, Backup-NAS nas02 im Schwesterstandort, beide auf TrueNAS SCALE 25.10. Auf nas01 liegt der Pool tank mit dem Dataset tank/fileserver, das mit einem 256-Bit-AES-Key verschlüsselt ist (Key-Format hex, gespeichert in der TrueNAS-KMIP-Schnittstelle bzw. lokal als verschlüsselte Datei).

1. Periodic Snapshot Task auf nas01 für tank/fileserver, rekursiv, alle 30 Minuten, Aufbewahrung 2 Wochen.
2. SSH-Connection von nas01 zu nas02 einrichten — semi-automatisch über die TrueNAS-UI, sodass der Public Key sauber im ~/.ssh/authorized_keys des Replication-Users liegt.
3. Replication Task anlegen: Source tank/fileserver, Destination backup/nas01/fileserver auf nas02. Transport: SSH+NETCAT (höchster Durchsatz im LAN) oder SSH (über WAN). Wichtig: Häkchen bei “Replicate encrypted dataset” und “Encryption” so setzen, dass der Stream als Raw Send läuft.
4. Properties Excludes prüfen — standardmäßig blendet TrueNAS einige Properties aus, die Encryption-Hierarchie bleibt aber erhalten.

Nach dem ersten Lauf erscheint backup/nas01/fileserver auf nas02 als verschlüsseltes, gesperrtes Dataset. zfs get keystatus zeigt unavailable, der Inhalt ist nicht montiert — genau richtig.

Key-Management: die Management-Station als zentrale Instanz

Die eigentliche Sicherheitsfrage ist nicht “Wird verschlüsselt?”, sondern “Wer hält den Schlüssel?”. Wir empfehlen Kunden in der Regel folgendes Modell:

Ort	Was liegt dort?	Zweck
Primär-NAS nas01	Key geladen, Dataset unlocked	Produktivbetrieb
Backup-NAS nas02	Key NICHT geladen, Dataset locked	Reine Block-Aufbewahrung
Management-Station	Master-Kopie aller Keys, GPG-verschlüsselt	Recovery, Audit, Schlüsselrotation
Offline-Tresor	Ausgedruckter Hex-Key bzw. Smartcard	Letzte Rückfallebene

Die Management-Station ist in unseren Setups ein gehärteter Linux-Client (Debian 13 oder ein dedizierter Mini-PC mit Disk-Encryption), auf dem die Keys in einer GPG-verschlüsselten Datei oder einer Pass-Datenbank liegen. Sie wird ausschließlich für Recovery- und Rotationsaufgaben verwendet — nicht für Tagesgeschäft.

Wichtig: Der Replication-User auf nas02 darf zwar Datasets anlegen und beschreiben, aber nicht automatisch Keys laden. Genau diese Trennung macht den Unterschied zwischen “Backup” und “zweiter Angriffspunkt”.

Recovery-Szenario: das Backup wird zum Primärsystem

Spielen wir einen Ernstfall durch. nas01 ist nach einem Wasserschaden defekt, der Pool ist verloren, der TPM-gestützte Key auf dem System ebenfalls. Auf nas02 liegen alle Snapshots als Raw-Replika. So bringen Sie die Daten wieder online:

# 1. An nas02 anmelden, Status prüfen
zfs list -t all backup/nas01/fileserver
zfs get keystatus,encryption,keyformat backup/nas01/fileserver

# 2. Key von der Management-Station holen (per scp aus GPG-Container)
#    und temporär auf nas02 ablegen, z.B. /root/keys/fileserver.key
chmod 600 /root/keys/fileserver.key

# 3. Key laden und Dataset entsperren
zfs load-key -L file:///root/keys/fileserver.key backup/nas01/fileserver
zfs mount backup/nas01/fileserver

# 4. Auf gewünschten Snapshot zurueckrollen, falls noetig
zfs list -t snapshot backup/nas01/fileserver | tail
zfs rollback backup/nas01/fileserver@auto-2026-06-25_22-00

# 5. Share neu freigeben (SMB/NFS-Config aus dem Konfig-Backup)
#    und Key-File wieder loeschen
shred -u /root/keys/fileserver.key

Dieser Ablauf dauert geübt unter zehn Minuten und benötigt genau einen kritischen Input: den Key von der Management-Station. Genau deshalb gehört in jedes Notfallhandbuch ein klarer Punkt “Schlüsselzugriff: wer, wie, wo”.

Häufige Stolperfallen aus der Praxis

Wir sehen bei Übernahmen immer wieder dieselben Muster, die im Recovery teuer werden:

• Key auf dem Backup-NAS dauerhaft geladen. Bequem, aber sicherheitstechnisch sinnlos — ein Einbruch in den Backup-Standort liefert sofort Klartext.
• Replication ohne Raw Send. Das Zweitsystem erbt entweder gar keine Verschlüsselung oder eine eigene Encryption-Root, deren Key niemand dokumentiert hat.
• Key nur im TrueNAS-Webinterface gespeichert. Wenn das Boot-Pool stirbt und kein Export existiert, ist der Key weg. TrueNAS bietet unter Datasets > Encryption Options den Export — nutzen Sie ihn nach jeder Rotation.
• Snapshots auf nas02 automatisch geprunt. Klingt logisch, ist aber gefährlich, wenn die Pruning-Policy strenger ist als auf dem Primärsystem. Wir konfigurieren die Aufbewahrung auf dem Ziel grundsätzlich länger als auf der Quelle.
• Keine regelmäßige Restore-Probe. Einmal pro Quartal sollte ein zufälliges Dataset auf einem isolierten System tatsächlich entsperrt und gemountet werden — alles andere ist Hoffnung, kein Backup.

DATAZONE als Sparringspartner

Verschlüsselte Replikation ist kein Hexenwerk, sie braucht aber ein durchdachtes Zusammenspiel aus Storage-Design, Key-Hygiene und dokumentierten Recovery-Prozessen. Wir bauen genau solche Setups für mittelständische Kunden in Bayern und darüber hinaus — mit klarem Runbook, getesteten Wiederherstellungen und nachvollziehbarem Key-Management.

DATAZONE unterstützt Sie bei der Planung, der Migration auf TrueNAS sowie beim Aufbau einer belastbaren Backup-Strategie inklusive Replikation. Sprechen Sie uns an — ein erstes Gespräch ist unverbindlich: Kontakt aufnehmen.