zfs create -o encryption=on …. Los hijos heredan. Rotar key en Linux: zfs change-key (no Solaris zfs key -c).

OpenZFS cifra datasets, no el pool entero. El pool (etiquetas, metaslab) sigue visible; el contenido de tank/secret no. Sirve en TrueNAS, Proxmox y Linux.

Guías útiles: Ars native encryption, ZFS encrypted backups.

Crear

1
2

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/encrypted
zfs create tank/encrypted/child1

child1 hereda cifrado. No pongas encryption=off en un hijo: OpenZFS no permite “agujero” sin cifrar bajo un padre cifrado.

Keyfile en vez de prompt:

1
2

zfs create -o encryption=on -o keyformat=passphrase \
  -o keylocation=file:///root/zfs.key tank/encrypted

El archivo de la key no va en el dataset cifrado. USB, TPM o un path en otro pool.

Cargar la key al boot

1
2

zfs load-key tank/encrypted
zfs mount tank/encrypted

Sin load-key, el dataset existe y zfs list lo muestra, pero no monta.

Recibir un dataset claro como cifrado

En el primer recv, puedes fijar propiedades de cifrado:

1
2
3

zfs send tank/test@snap1 \
  | zfs recv -o encryption=on -o keyformat=passphrase \
      -o keylocation=file:///path/to/keyfile tank/encrypted

Eso es un receive sin -w. -w (raw) copia el wrapping key del origen: solo aplica si el origen ya estaba cifrado. Detalle en send de dataset sin cifrar a cifrado.

Rotar passphrase (OpenZFS)

En Solaris el comando era zfs key -c. En OpenZFS / Linux / TrueNAS:

1
2

zfs change-key tank/encrypted
zfs get keyformat,keylocation,keystatus tank/encrypted

Keyfile nueva:

1

zfs change-key -o keylocation=file:///media/stick/key tank/encrypted

rekey de wrapping key (no re-cifra todos los bloques; rota la key que envuelve las master keys) es zfs change-key -i según versión — lee zfs change-key de tu man page antes de usarlo en producción.

Ver también: hold de snapshots, backups fuera del host.

Primer recv con -o encryption=on (sin -w). El dataset destino debe existir con nombre.

Quieres el mismo contenido, otra key. El origen sigue en claro; el destino nace cifrado. OpenZFS lo permite solo en el receive inicial (dataset que todavía no existe).

Hilo de origen: r/zfs.

Comando

1
2
3
4
5
6

zfs snapshot tank/test@snap1
zfs send tank/test@snap1 \
  | zfs recv -o encryption=on \
      -o keyformat=passphrase \
      -o keylocation=file:///path/to/keyfile \
      tank/encrypted

Notas que rompen el send si se omiten:

1. No uses -w. Raw send reproduce el estado de cifrado del origen. Origen en claro → destino en claro, y los -o encryption=… se ignoran o fallan.
2. Pon el nombre del dataset destino (tank/encrypted). Un recv sin destino no crea el dataset.
3. Passphrase vs file: keylocation=prompt no funciona bien al otro lado de un pipe no interactivo. Keyfile o keylocation=file://.
4. Los incrementales siguientes (-i) heredan el cifrado. No vuelvas a pasar -o encryption=on.

Comprobar

1
2

zfs get encryption,keystatus,keyformat tank/encrypted
zfs load-key tank/encrypted   # si keystatus=unavailable

El otro sentido

Cifrado → cifrado con la misma wrapping key: zfs send -w. Cifrado → otro key wrapping: send sin -w (ZFS descifra al enviar; el recv vuelve a cifrar). Eso exige load-key en el origen y es más lento.

Ver también: cifrado nativo.