En corto

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.