{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreibkwtr45nvld63e3j2uxgweiilstc332qzo4sqrovabghi4ckj2se",
"uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmdyxm52bnm2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreihugqgpwtseosevcmfraleis4rvbin5gb63nhtydh6ay5fqksk72y"
},
"mimeType": "image/png",
"size": 682269
},
"description": "ZFS Encryption nachtraeglich aktivieren geht nicht. Datasets muessen per zfs send|receive in ein neues verschluesseltes Ziel kopiert werden. Anleitung mit Stolperfallen, inkrementeller Migration und encrypted Offsite-Backup via zfs send -w.",
"path": "/2021/04/26/freebsd-13-unverschluesseltes-zfs-dataset-jail-zu-verschluesseltem-zfs-dataset-jail/",
"publishedAt": "2026-05-21T08:30:30.000Z",
"site": "https://www.kernel-error.de",
"tags": [
"Encryption",
"FreeBSD",
"Hardening",
"InfoSec",
"Jail",
"Storage",
"Sysadmin",
"ZFS",
"Native ZFS Encryption einrichten",
"Native ZFS Encryption einrichten und nutzen",
"Verschlüsseltes ZFS-Backup auf USB-Platte mit geli",
"Linux Mint mit verschlüsseltem ZFS-Root-Pool installieren",
"ZFS-Überblick",
"Einfach melden.",
"@migration-1"
],
"textContent": "ZFS Encryption lässt sich nicht nachträglich auf ein bestehendes Dataset aktivieren. Die Daten müssen per `zfs send | zfs receive` in ein neues, verschlüsseltes Dataset geschrieben werden. Typischer Anwendungsfall: Jails, die in eigenen Datasets liegen und nach einem FreeBSD-Upgrade auf 13+ verschlüsselt werden sollen.\n\nWer die Grundlagen zu ZFS Encryption noch braucht (Dataset anlegen, Passphrase, Mount nach Reboot), findet sie im Beitrag Native ZFS Encryption einrichten.\n\n### Ausgangslage\n\nEin Pool `zroot` mit dem unverschlüsselten Dataset `varta`:\n\n\n zfs list zroot/varta\n NAME USED AVAIL REFER MOUNTPOINT\n zroot/varta 100M 12.0G 100M /zroot/varta\n\n zfs get encryption zroot/varta\n NAME PROPERTY VALUE SOURCE\n zroot/varta encryption off default\n\n### Migration\n\nBei `zfs send | zfs receive` kann man kein Passphrase interaktiv eingeben, weil stdin durch die Pipe belegt ist. Deshalb legt man den Schlüssel temporär in einer Datei ab:\n\n\n echo 'MeinGeheimesPassphrase' > /tmp/keyfile.txt\n chmod 600 /tmp/keyfile.txt\n\nSnapshot erstellen und in ein neues verschlüsseltes Dataset senden:\n\n\n zfs snapshot zroot/varta@migration\n\n zfs send zroot/varta@migration | \\\n zfs receive -F \\\n -o encryption=on \\\n -o keyformat=passphrase \\\n -o keylocation=file:///tmp/keyfile.txt \\\n zroot/en-varta\n\nDas neue Dataset `zroot/en-varta` enthält jetzt dieselben Daten, verschlüsselt mit AES-256-GCM:\n\n\n zfs list zroot/varta zroot/en-varta\n NAME USED AVAIL REFER MOUNTPOINT\n zroot/en-varta 100M 11.8G 100M /zroot/en-varta\n zroot/varta 100M 11.8G 100M /zroot/varta\n\n### Aufräumen\n\nDie Keyfile-Referenz auf Passphrase-Abfrage umstellen und die temporäre Datei löschen:\n\n\n zfs set keylocation=prompt zroot/en-varta\n\n zfs get keylocation zroot/en-varta\n NAME PROPERTY VALUE SOURCE\n zroot/en-varta keylocation prompt local\n\n rm /tmp/keyfile.txt\n\nDann das alte Dataset entfernen und das neue umbenennen:\n\n\n zfs destroy -r zroot/varta\n zfs rename zroot/en-varta zroot/varta\n\nFertig. Das Dataset liegt jetzt verschlüsselt am selben Mountpoint wie vorher:\n\n\n zfs get encryption,keylocation,keyformat zroot/varta\n NAME PROPERTY VALUE SOURCE\n zroot/varta encryption aes-256-gcm -\n zroot/varta keylocation prompt local\n zroot/varta keyformat passphrase -\n\n### Stolperfallen\n\n**Keyfile in /tmp ist ein Kompromiss.** Auf FreeBSD-Default ist `/tmp` zwar ein `tmpfs` im RAM, aber bei Speicherdruck kann das System swappen. `chmod 600` schützt gegen andere Benutzer, nicht gegen root, Backup-Prozesse oder einen Crash-Dump. Sauberer ist eine `keylocation` auf einem schon verschlüsselten Dataset oder ein FIFO statt einer regulären Datei. In beiden Fällen existiert die Passphrase nie persistent auf der Platte.\n\n**Properties gehen beim Send verloren.** Ohne `-R` (Replication Stream) oder explizite `-o`-Optionen werden `compression`, `recordsize`, `quota`, `reservation`, `atime` und eigene Properties nicht mitübertragen. Wer `compression=zstd` oder `recordsize=1M` gesetzt hatte, muss die beim `receive` wieder setzen oder direkt einen Replication Stream nutzen.\n\n**Mountpoint nach dem Rename prüfen.** Lag das alte Dataset auf `/var/jails/varta`, muss der Mountpoint nach dem Rename wieder explizit gesetzt werden, sonst landet das Dataset am Default-Pfad des Pools:\n\n\n zfs set mountpoint=/var/jails/varta zroot/varta\n\n**Jail vorher stoppen.** `service jail stop <name>` bzw. `iocage stop` oder `bastille stop`. Sonst sind Dateien offen, `zfs destroy -r` schlägt fehl und der Rename macht keinen Spaß.\n\n### Inkrementelle Migration für große Datasets\n\nBei Jails mit Datenbank, Mailspool oder einfach mehreren hundert GB ist Downtime gleich Send-Laufzeit nicht akzeptabel. Besser: initial senden während der Dienst läuft, dann nur kurz stoppen und den inkrementellen Rest nachziehen.\n\n\n # Phase 1: initialer Send im laufenden Betrieb\n zfs snapshot zroot/varta@migration-1\n zfs send zroot/varta@migration-1 | \\\n zfs receive -F \\\n -o encryption=on \\\n -o keyformat=passphrase \\\n -o keylocation=file:///tmp/keyfile.txt \\\n zroot/en-varta\n\n # Phase 2: Dienst stoppen, inkrementelles Delta senden\n service jail stop varta\n zfs snapshot zroot/varta@migration-2\n zfs send -i @migration-1 zroot/varta@migration-2 | \\\n zfs receive zroot/en-varta\n\n # Phase 3: Rename und Neustart\n zfs destroy -r zroot/varta\n zfs rename zroot/en-varta zroot/varta\n zfs set mountpoint=/var/jails/varta zroot/varta\n service jail start varta\n\nDie Downtime reduziert sich so auf den inkrementellen Send plus Rename, bei einer typischen Mailbox sind das Sekunden statt Minuten. Bei sehr aktiven Datasets kann man mehrere inkrementelle Snapshots nacheinander schieben, bis das Delta klein genug für die gewünschte Zielzeit ist.\n\n### Update 2026: was heute dazugekommen ist\n\nOpenZFS 2.x ist auf FreeBSD 14 und 15 stabil. Der eigentliche Migrationspfad hat sich nicht geändert, drumherum ist einiges dazugekommen:\n\n**Raw encrypted send/receive.** Mit `zfs send -w` wird ein verschlüsseltes Dataset ohne Entschlüsselung übertragen. Der Remote-Host lagert den Stream, kennt den Schlüssel nicht und sieht keinen Klartext. Für Offsite-Backups der saubere Weg, sobald die Migration durch ist:\n\n\n zfs snapshot zroot/varta@backup\n zfs send -w -R zroot/varta@backup | \\\n ssh backup@remote zfs receive backuppool/varta\n\n**Andere Keyformate.** Statt `keyformat=passphrase` gehen auch `keyformat=raw` (32-Byte-Keyfile, z.B. aus HSM oder TPM) oder `keyformat=hex` (64 Zeichen Hex). `keylocation=https://...` holt den Schlüssel beim Pool-Import von einer URL, praktisch für headless Systeme, bei denen die Passphrase-Abfrage beim Boot stört.\n\n**Kompression vor Verschlüsselung.** ZFS komprimiert zuerst, verschlüsselt danach. `compression=zstd` zusammen mit `encryption=on` wirkt also wie erwartet, und der komprimierte Zustand bleibt auch im Raw Stream erhalten.\n\n**Nur für Datenpools und Non-Root-Datasets.** Diese Anleitung deckt Jails, Home-Verzeichnisse, Mailspools und ähnliches ab. Verschlüsseltes Root-on-ZFS ist ein eigenes Thema und braucht zusätzlich Boot-Environment-Handling (`bectl`) sowie ein geli-verschlüsseltes Swap.\n\n### Siehe auch\n\nNative ZFS Encryption einrichten und nutzen für die Grundlagen zu Dataset, Passphrase und Mount nach Reboot. Verschlüsseltes ZFS-Backup auf USB-Platte mit geli für die Offline-Sicherung. Linux Mint mit verschlüsseltem ZFS-Root-Pool installieren für das Linux-Pendant mit Root-Pool.\n\nEine Übersicht über alle ZFS-Funktionen gibt es im ZFS-Überblick. Fragen? Einfach melden.",
"title": "FreeBSD: Unverschlüsseltes ZFS-Dataset nachträglich verschlüsseln"
}