¿Por qué un token de reanudación de ZFS Send deja de funcionar después de que se reinicia el destino?
Un reinicio del destino normalmente no debería invalidar un token de reanudación de ZFS, a menos que hayan cambiado el estado de recepción guardado, el conjunto de datos o el historial de origen necesario.
El token es una descripción opaca de una recepción interrumpida específica, no un marcador reutilizable para cualquier intento de replicación posterior. Pertenece al sistema de archivos o volumen de destino que conservó el estado parcial mediante una recepción reanudable. Después de reiniciar, una tarea podría leer el conjunto de datos equivocado, importar el grupo de almacenamiento de otra forma, borrar el estado parcial, modificar el destino, perder una instantánea de origen necesaria o generar un flujo incompatible. Verifica el token en ambos extremos antes de reiniciar una transferencia completa.
Confirma que el estado de recepción parcial sobrevivió al reinicio
En el destino, lee la propiedad receive_resume_token del sistema de archivos o volumen exacto utilizado por la recepción interrumpida. Registra el nombre del grupo de almacenamiento, la ruta del conjunto de datos, el valor del token y el uso de espacio del estado parcial.
El manual de FreeBSD explica que las recepciones reanudables conservan el estado parcial y mantienen un token opaco en el conjunto de datos receptor hasta que la transferencia finaliza o el estado se abandona explícitamente.
Si la propiedad está vacía después del reinicio, la recepción no se guardó con la opción reanudable, el estado parcial se completó o se canceló, se está consultando el conjunto de datos equivocado o una limpieza automatizada lo eliminó. No reutilices un token copiado de una transferencia anterior.
Verifica que el token pertenece al conjunto de datos de destino exacto
Comprueba si el grupo de almacenamiento de destino se importó con el nombre esperado y si la replicación sigue apuntando a la misma ruta del conjunto de datos. Presta atención a las raíces alternativas, los grupos de almacenamiento renombrados, los cambios en las rutas principales y las opciones de tarea que añaden o eliminan componentes de la ruta.
La referencia de propiedades de ZFS de Ubuntu define receive_resume_token como una propiedad del conjunto de datos, lo que significa que el token debe leerse del sistema de archivos o volumen que contiene ese estado guardado específico.
No se puede suponer de forma segura que un token obtenido de backup/pool/data reanudará una recepción que ahora apunta a backup/data. Corrige la ruta de la tarea antes de cambiar instantáneas o destruir la recepción parcial.
Comprueba si el destino se modificó o se revirtió
Inspecciona los comandos, las tareas programadas, el software de replicación, la retención de instantáneas y la actividad del administrador desde la interrupción. Busca reversiones, promociones de clones, cambios de nombre del conjunto de datos, cancelaciones de recepciones o una nueva recepción en el mismo destino.
Klara Systems señala que las herramientas de replicación gestionan el estado del destino en torno a ZFS send y receive, por lo que una tarea de orquestación puede invalidar la ruta de recuperación original al limpiar o reemplazar el estado guardado.
No escribas archivos normales en un destino de replicación mientras investigas. Aunque el token siga existiendo, los cambios en el destino pueden bloquear el flujo o forzar una reversión que destruya datos más recientes del destino.
Verifica que el origen aún tenga la cadena de instantáneas o marcadores
Identifica el conjunto de datos de origen y las instantáneas o marcadores codificados por la transferencia interrumpida. Compáralos con la retención actual y con cualquier cambio de nombre o eliminación de instantáneas desde que se detuvo la transferencia.
El manual de zfs-send de FreeBSD especifica que zfs send -t genera un flujo a partir del token de reanudación de la recepción, vinculando el nuevo flujo con la recepción interrumpida en lugar de con una instantánea actual arbitraria.
Si la retención eliminó el historial de origen necesario, el token no puede reconstruir datos que ya no existen. Conserva el estado parcial restante del destino hasta decidir si necesitas otra copia del origen o un envío completo nuevo.
Comprueba las funciones del grupo de almacenamiento y las opciones del flujo en ambos sistemas
Registra las versiones de ZFS, las funciones habilitadas del grupo de almacenamiento, el estado del cifrado y las opciones originales del flujo, como envíos sin procesar, comprimidos, integrados o de bloques grandes. Compáralos después de cualquier actualización del software o del grupo de almacenamiento.
La documentación de Oracle sobre replicación reanudable describe la reanudación de una transferencia interrumpida como una operación coordinada de envío y recepción, por lo que la compatibilidad y el contexto de la transferencia original siguen siendo importantes después de un reinicio.
Un reinicio por sí solo no cambia los indicadores de funciones, pero una actualización realizada durante la interrupción sí puede hacerlo. Reproduce manualmente el comando de reanudación con una salida detallada antes de asumir que el token está dañado.
Verifica los servicios de replicación y SSH después del arranque del destino
Confirma que el grupo de almacenamiento de destino esté importado, que los conjuntos de datos cifrados necesarios estén desbloqueados, que SSH esté en ejecución, que el usuario de replicación pueda ejecutar comandos de ZFS y que la tarea se inicie solo después de que el almacenamiento esté listo.
Las indicaciones de TrueNAS sobre replicación remota requieren que los requisitos previos de SSH y del conjunto de datos de destino estén disponibles después de reiniciar; de lo contrario, la automatización puede fallar antes incluso de intentar usar el token guardado.
Prueba la autenticación y una consulta de propiedades de solo lectura antes de iniciar el flujo reanudado. Un fallo de red o de permisos puede parecer un fallo del token en el registro de una tarea de alto nivel.
Reanuda una vez o cancela deliberadamente la recepción parcial
Genera un único flujo de envío reanudado utilizando el token actual y pásalo a una recepción reanudable en el mismo destino. Guarda toda la salida de error y evita iniciar tareas de replicación en paralelo.
La guía de migración de datos NAS de ZimaSpace proporciona la regla de seguridad relacionada: conserva el origen y la ruta de reversión hasta verificar el destino.
Si el token no se puede utilizar y el estado parcial ya no es valioso, cancélalo con el comando compatible de cancelación de recepción solo después de confirmar que se puede generar una transferencia completa o incremental nueva. La cancelación libera el estado parcial guardado y no se puede deshacer.
Preguntas frecuentes
¿Un reinicio del destino siempre invalida un token de reanudación de ZFS?
No. Una recepción parcial guardada está diseñada para sobrevivir a interrupciones, incluido un apagado incorrecto. Un fallo después del reinicio normalmente significa que la tarea está leyendo otro conjunto de datos, que el estado parcial se borró, que cambió el historial de origen necesario o que faltan dependencias de arranque.
¿Se puede generar un token de reanudación nuevo únicamente desde el origen?
No. El token opaco procede del estado de recepción parcial guardado en el conjunto de datos de destino. El origen utiliza ese token para generar un flujo de continuación, pero no puede recrear por sí solo un estado de destino eliminado.
¿Cuándo debe cancelarse la recepción parcial?
Cancélala únicamente cuando se haya demostrado que la ruta de reanudación no se puede utilizar, el origen pueda generar una transferencia de reemplazo y el estado parcial del destino ya no sea necesario para la recuperación. Conserva los registros y las instantáneas disponibles antes de eliminarlo.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
