1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Receptor preparado para reanudar: -s en el recv
zfs send -v -w tank/data@snap1 | ssh backup-host zfs recv -s backup/data

# Se cortó. En el receptor, pide el token:
zfs get -H -o value receive_resume_token backup/data

# En el emisor, retoma desde ese punto (sin nombrar dataset ni snapshot: el token lo lleva todo):
zfs send -v -t 1-d4f61d893-c0-789c636064000310a500c4ec50360710e72765a5… | ssh backup-host zfs recv -s backup/data

# Rendirse y liberar lo recibido a medias:
zfs recv -A backup/data

Funciona igual con envíos incrementales (-i / -I) y con envíos raw de datasets cifrados (-w).

Por qué

Sin -s, un zfs recv interrumpido descarta todo lo que había recibido: horas de transferencia a la basura por un corte de red o un reinicio. Con -s (OpenZFS desde 2017; Linux 0.7+, FreeBSD 12+) el receptor conserva el trozo recibido en un dataset oculto (backup/data/%recv) y expone la propiedad receive_resume_token.

El token es la descripción completa de lo que falta: identifica el snapshot origen, el objeto y el offset donde se quedó, y las opciones del stream (raw, comprimido, bloques grandes…). Por eso zfs send -t no necesita más argumentos y por eso no hace falta acordarse de qué flags llevaba el send original: se reconstruyen desde el token.

Paso a paso

1. Recibe siempre con -s. No cuesta nada y es lo único que hay que recordar antes del corte.

2. Tras la interrupción, en el receptor:

   1	zfs get -H -o value receive_resume_token backup/data

   Si devuelve -, no hay estado parcial (el envío terminó o nunca empezó).

3. En el emisor, zfs send -t <token> con la misma tubería de siempre hacia zfs recv -s. Puedes cortarlo y retomarlo tantas veces como haga falta; cada vez el token cambia.

4. Comprueba el final: zfs get receive_resume_token vuelve a - y el snapshot aparece en zfs list -t snapshot -r backup/data.

Para ver el progreso, -v en el send (bytes enviados) o pv en medio; para amortiguar latencia en enlaces lentos, mbuffer entre send y ssh.

Abortar

1

zfs recv -A backup/data

Borra el %recv y libera el espacio. Necesario cuando el token ya no sirve (abajo) o cuando decides reenviar desde otro snapshot.

Con syncoid

syncoid usa recv -s y los tokens por su cuenta: si un envío se corta, la siguiente ejecución lo retoma sola. --no-resume lo desactiva si alguna vez estorba. Sanoid + syncoid son la forma cómoda de hacer esto en producción.

Trampas

• Destruir el snapshot origen invalida el token. Si tu política de snapshots (o zfs destroy a mano) se lleva @snap1 a medio envío, el send -t falla: zfs recv -A y empieza desde un snapshot que exista. Un hold sobre el snapshot que estás enviando evita el problema.
• Los dos extremos tienen que soportarlo: OpenZFS moderno en ambos. Solaris e Illumos antiguos no entienden -s.
• -w se conserva en el token: un envío raw reanudado sigue siendo raw; no intentes mezclar un send -t con un recv de destino distinto del original.
• Mientras hay estado parcial, zfs destroy del dataset destino se queja: primero recv -A.
• Streams -R (paquetes con varios snapshots) también se reanudan, pero es más simple enviar snapshot por snapshot con -i, que es lo que hace syncoid.

Ver también

• Enviar snapshots ZFS a otro host (y de ahí a S3)
• zfs send/recv de un dataset sin cifrar a uno cifrado
• Proteger snapshots con hold