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.

zfs send -w -R -i por SSH a zfs recv -s. El stream no es tar; S3 es el paso extra si lo necesitas.

zfs send produce un stream replicable, no un directorio. El destino natural es otro pool (zfs recv). S3 es un segundo salto: guardas el stream como objeto, o usas una herramienta tipo z3.

Incremental a otro host (el comando que uso)

1
2

zfs send -w -R -v -i vol1/secure/backups@initial vol1/secure/backups@new \
  | ssh root@10.0.0.1 zfs recv -s vol1/secure/backups

Pon un hold en @initial y @new mientras corre el send, o el prune te rompe la cadena.

El primer full (sin -i) es obligatorio una vez:

1
2

zfs send -w -R -v vol1/secure/backups@initial \
  | ssh root@10.0.0.1 zfs recv -s vol1/secure/backups

Aterrizar en S3

Mismo stream, otro lado del pipe:

1
2
3

zfs send -w -R vol1/secure/backups@new \
  | gzip -1 \
  | aws s3 cp - s3://mi-bucket/zfs/backups@new.zfs.gz

Restaurar:

1
2
3

aws s3 cp s3://mi-bucket/zfs/backups@new.zfs.gz - \
  | gunzip \
  | zfs recv -s vol1/secure/backups

Esto no es un sync de archivos. Es un blob opaco: o recuperas el stream entero (o el incremental encima del full), o no recuperas nada. Versiona los nombres @initial, @new y no borres el full.

Para incrementales en S3, herramientas como z3 llevan el catálogo de qué snapshot ya subió. Un aws s3 cp - crudo no sabe de eso.

-w en S3 es correcto si el dataset ya está cifrado: Amazon no ve plaintext. Si el origen no está cifrado, o cifras en recv (artículo) o cifras el objeto (KMS / cliente) — el stream en claro en un bucket es un backup en claro.

Ver también: cifrado nativo.

ZVOL = block device: dd if=/dev/zvol/pool/vol of=vm.raw. Snapshot primero si la VM está up.

En Proxmox un disco de VM en ZFS es un ZVOL (rpool/data/vm-101-disk-0), no un archivo. Para copiarlo a otro hypervisor o a un USB, sacas un RAW.

Hilo: Import/convert/export RAW images to ZFS volume.

Snapshot y dd

Si la VM está encendida, congela el disco con un snapshot y lee el snap (el ZVOL @snap aparece bajo /dev/zvol/…):

1
2
3

zfs snapshot rpool/data/vm-101-disk-0@export
dd if=/dev/zvol/rpool/data/vm-101-disk-0@export of=/mnt/backup/vm-101.raw bs=1M status=progress
zfs destroy rpool/data/vm-101-disk-0@export

VM apagada, puedes leer el zvol vivo:

1

dd if=/dev/zvol/rpool/data/vm-101-disk-0 of=/mnt/backup/vm-101.raw bs=1M status=progress

bs=1M (o 1m en dd GNU) importa: el default de 512 B es eterno.

qemu-img (qcow2 / vmdk)

1

qemu-img convert -p -f raw -O qcow2 /mnt/backup/vm-101.raw /mnt/backup/vm-101.qcow2

O directo desde el zvol:

1

qemu-img convert -p -f raw -O qcow2 /dev/zvol/rpool/data/vm-101-disk-0 vm-101.qcow2

El otro sentido (RAW → ZVOL)

1
2

zfs create -s -V 32G rpool/data/vm-101-disk-0
dd if=file.raw of=/dev/zvol/rpool/data/vm-101-disk-0 bs=1M status=progress

-s = sparse. El RAW no puede ser más grande que el zvol.

Ver también: comandos básicos.

Pool no importa tras apagón: zpool import -f, si hace falta -F (rewind txgs), luego zpool scrub.

Tras un corte de luz el pool a menudo existe en los discos pero zpool status no lo muestra: quedó exportado sucio o el host arrancó sin él. No hagas zpool create sobre esos discos.

Ver qué hay

1

zpool import

Lista pools importables con su nombre (VOL1 en el ejemplo) y si están FAULTED / UNAVAIL.

Importar

1

zpool import -f VOL1

-f = “sé que puede estar importado en otro host”. Es el caso típico después de un crash: ZFS cree que el otro lado todavía lo tiene.

Si -f no basta porque las últimas txgs quedaron a medias:

1

zpool import -F VOL1

-F rebobina a un txg anterior consistente. Puedes perder los segundos de writes del apagón. Es preferible a un pool que no monta.

-n simula:

1

zpool import -F -n VOL1

Después: scrub

1
2

zpool scrub VOL1
zpool status VOL1

El scrub confirma que el rewind no dejó checksum errors. Déjalo terminar antes de borrar snapshots “por si acaso”.

Qué no hacer

• zpool create sobre los mismos sdX destruye las etiquetas.
• -F no es el primer recurso: prueba -f primero.
• Si el pool es raíz (rpool / bpool de Proxmox), importa desde un live USB, no desde el sistema que no arranca.

Ver también: reemplazar discos, comandos básicos.

zfs hold keep pool/dataset@snap — zfs destroy falla con dataset is busy. Suelta con zfs release.

Los scripts de retención (zfs destroy -r …@auto-…) no preguntan. Un hold es un candado con nombre sobre un snapshot: destroy falla hasta que sueltas el tag.

Sirve para la snapshot desde la que estás haciendo zfs send, o para la que es el único rollback conocido después de un upgrade.

Poner el hold

1

zfs hold keep tank/home/cindys@snap1

Recursivo en todo un árbol (primero snapshot, luego hold):

1
2

zfs snapshot -r tank/home@now
zfs hold -r keep tank/home@now

El tag (keep) es libre, pero único por snapshot. Puedes tener keep y offsite a la vez en el mismo @now.

Qué ves al destruir

1
2

zfs destroy tank/home/cindys@snap1
# cannot destroy 'tank/home/cindys@snap1': dataset is busy

Eso es el hold, no un dataset montado. zfs destroy -d marca el snapshot para borrar cuando no queden holds (diferido), no lo ignora.

Listar

1
2

zfs holds tank/home@now
zfs holds -r tank/home@now

1
2
3

NAME                  TAG   TIMESTAMP
tank/home@now         keep  Thu Jul 15 11:25:39 2010
tank/home/cindys@now  keep  Thu Jul 15 11:25:39 2010

Soltar y entonces sí destruir

1
2

zfs release -r keep tank/home@now
zfs destroy -r tank/home@now

Si un send largo sigue corriendo, espera a que termine: el hold está precisamente para que el prune no te coma el cursor incremental.

Docs de Oracle (el mecanismo es el mismo en OpenZFS): Holding ZFS snapshots.

Ver también: send a dataset cifrado.

Disco OFFLINE: zpool replace -f <GUID> /dev/disk/by-id/… — el GUID lo da zpool status, no /dev/sdX.

Proxmox documenta el caso: ZFS on Linux — change a failed device. El síntoma es un vdev OFFLINE / FAULTED y un número largo en vez de sde.

Estado

1

zpool status vol1

Ejemplo: el miembro muerto aparece como GUID:

1

1894156996840098641  OFFLINE

Eso pasa cuando el kernel ya no tiene /dev/sdX para ese disco (lo arrancaste, se fue, o cambió de letra).

Replace

1

zpool replace -f vol1 1894156996840098641 /dev/disk/by-id/ata-NEWDISK

-f fuerza si ZFS todavía “recuerda” el disco viejo. El destino debe ser al menos del mismo tamaño (mejor, by-id, no sde).

Si el disco nuevo es el mismo slot y ZFS lo ve:

1

zpool replace vol1 /dev/disk/by-id/ata-OLDDISK /dev/disk/by-id/ata-NEWDISK

o, autodetect del recambio en el mismo sitio:

1

zpool replace vol1 /dev/disk/by-id/ata-OLDDISK

Esperar el resilver

1
2

zpool status vol1
watch -n 5 zpool status vol1

No apagues el host, no exportes el pool, no hagas otro replace en el mismo vdev hasta resilvered. En RAIDZ1 estás un disco abajo: un segundo fallo en ese periodo es pérdida.

Después

1
2

zpool detach vol1 1894156996840098641   # solo si quedó como spare/old y status lo pide
zpool labelclear /dev/sdOLD             # si reusas el disco viejo en otra máquina

Ver también: import después de apagón.

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.

Cheat sheet: zpool create, export/import, lz4, L2ARC, SLOG, labelclear, destroy — lo de las 2 a.m.

Referencia corta. Los procedimientos largos están enlazados al final.

Pool

1
2
3
4
5
6

zpool create vol1 raidz sda sdb sdc
zpool status vol1
zpool export vol1
zpool import -f vol1
zpool destroy tank          # irreversible
zpool labelclear ada0       # limpia etiquetas ZFS de un disco suelto

raidz aquí es RAIDZ1 (una paridad). Para dos: raidz2. Identifica discos por /dev/disk/by-id/…, no por sdX que se reordenan.

Mountpoint

1
2
3

zfs unmount vol1
zfs set mountpoint=/mnt/vol1 vol1
zfs mount vol1

L2ARC (cache) y SLOG (ZIL)

1
2
3
4

zpool add vol1 cache <disk-id>
zpool add vol1 log <disk-id>
zpool add vol1 log mirror <disk-id-a> <disk-id-b>
zpool remove vol1 <device>

Cache = lecturas calientes. Log = sync writes (NFS, VMs). Un SLOG USB “rápido” es peor que no tener SLOG: si muere a mitad de un txg, duele. Espeja el log.

Compression

1
2
3

zfs set compression=lz4 newvol
zfs set compression=off newvol
zfs get compressratio newvol

lz4 es el default razonable en OpenZFS moderno. zstd comprime más y cuesta CPU. La propiedad se hereda a datasets hijos que no la pisen.

Ver también

• Importar después de un apagón
• Reemplazar discos
• Cifrado nativo