Cómo verificar que la replicación de ZFS puede reanudarse después de una transferencia interrumpida

Sí, cuando el lado receptor conserva un token de reanudación válido y las instantáneas de origen necesarias para ese token siguen existiendo.

La decisión es importante cuando un envío raw o incremental de ZFS se interrumpe por una interrupción de red o del destino. Los dos estados en competencia son un token de reanudación de recepción válido y la ausencia del token o la destrucción de la instantánea de origen. Comience con una configuración guardada y datos desechables, observe una rama a la vez y deténgase si la prueba aumenta el riesgo de pérdida de datos, permisos o disponibilidad.

Defina las condiciones detrás de la decisión de replicación reanudable de ZFS

Registre el entorno antes de cambiar nada: versiones de software y firmware, identidades de los dispositivos, ruta de montaje o red, espacio libre, permisos y síntoma observable. La línea base debe conservar suficientes detalles para reproducir la interrupción de un envío raw o incremental de ZFS por una interrupción de red o del destino.

El primer candidato es un token de reanudación de recepción válido. El segundo es la ausencia del token o la destrucción de la instantánea de origen. El envío reanudable de ZFS actual define el mecanismo o límite del comando utilizado en la prueba; no sustituye la observación de este servidor doméstico específico.

Escriba la condición de aceptación y la condición de parada antes de ejecutar el discriminador. Una aprobación debe cambiar la evidencia predicha por una rama sin modificar los servicios no relacionados; un fallo debe devolver el sistema al estado guardado en lugar de activar una cadena de correcciones especulativas.

Pruebe la afirmación sin reducir el requisito original

Use este discriminador: interrumpa una replicación desechable, lea el token, genere un flujo de envío reanudado y compare la instantánea final del destino. Mantenga constantes la carga de trabajo, el cliente, la ruta, el conjunto de archivos y el tiempo para que el resultado pueda atribuirse a la variable modificada.

Use envío y recepción de ZFS para seleccionar el campo que realmente pueda separar las ramas y capture su marca de tiempo, estado de salida, texto del error, identidad del dispositivo o de la instantánea, latencia, bytes transferidos, permisos y estado de recuperación. Una salida limpia del comando no es suficiente cuando la identidad, la durabilidad o el estado de la aplicación son la afirmación que se está probando.

Repita la prueba una vez después de un reinicio, una reconexión, un nuevo montaje o una caché fría cuando ese evento forme parte de la condición original. Si la primera ejecución es destructiva o el entorno no puede restaurarse, deténgase y reproduzca la prueba en una copia desechable.

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

Interprete los resultados de aprobación, fallo y excepción

APROBACIÓN: el flujo de reanudación se completa y las instantáneas de origen y destino comparten la ascendencia GUID esperada. Registre la versión exacta, la identidad y la carga de trabajo que resultaron satisfactorias para que la conclusión siga siendo condicional en lugar de convertirse en una afirmación universal.

FALLO: no existe ningún token, el destino se revirtió o se eliminaron las instantáneas de origen necesarias. Un fallo no demuestra automáticamente la rama opuesta cuando la red, la memoria, los permisos o la coherencia del origen pueden influir en ambas; aísle esas dependencias compartidas antes de escalar.

RESULTADO EXCEPCIONAL O AMBIGUO: cancele la recepción parcial solo después de decidir que el coste del reinicio es aceptable. Conserve los registros y no ejecute comandos de reparación, depuración, destrucción, reparticionado o cambio recursivo de propietario hasta que exista una copia recuperable.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirme la decisión con la carga de trabajo original

Aplique la acción correspondiente a la rama observada y repita después la condición original, no un sustituto reducido. La decisión solo se mantiene cuando el flujo de reanudación se completa y las instantáneas de origen y destino comparten la ascendencia GUID esperada durante dos ciclos o durante el reinicio, suspensión, interrupción o transición de carga correspondiente.

Use las ventanas de copia de seguridad inmutables para comprobar el flujo de trabajo dependiente más cercano, pero mantenga sin cambios el activador original. Los conjuntos de datos, recursos compartidos, contenedores, usuarios y puntos de recuperación no relacionados deben conservar su acceso y sus tiempos anteriores.

El límite de parada es explícito: si no existe ningún token, el destino se revirtió o se eliminaron las instantáneas de origen necesarias, vuelva a la última configuración verificada, conserve la evidencia y escale a una prueba más profunda de la plataforma o del hardware solo cuando la rama sea reproducible.

Una vez obtenido el resultado objetivo, compárelo con el diseño del repositorio local para que la solución no traslade el riesgo a un servicio vecino. Una prueba objetivo satisfactoria con un nuevo fallo de copia de seguridad, identidad, tiempo de espera o disponibilidad sigue siendo un cambio fallido.

Preguntas frecuentes

En la replicación reanudable de ZFS, las búsquedas restantes suelen referirse a si toda recepción interrumpida crea un token, si pueden eliminarse las instantáneas de origen antiguas después de una interrupción y cómo se verifica la réplica final. Las respuestas siguientes mantienen esos casos límite separados de la decisión principal.

El límite de aceptación no cambia: el flujo de reanudación se completa y las instantáneas de origen y destino comparten la ascendencia GUID esperada. Si una condición posterior cambia el sistema de archivos, la identidad, la ruta de red o la versión de la aplicación, repita únicamente el discriminador afectado por ese cambio.

Deje de ampliar el experimento cuando no exista ningún token, el destino se haya revertido o se hayan eliminado las instantáneas de origen necesarias. En ese punto, cancele la recepción parcial solo después de decidir que el coste del reinicio es aceptable; conserve la evidencia antes de escalar al responsable de la plataforma, el almacenamiento o el hardware.

¿Toda recepción interrumpida crea un token?

No. La recepción debe utilizar un comportamiento reanudable y fallar en un estado que conserve un token.

¿Pueden eliminarse las instantáneas de origen antiguas después de una interrupción?

No hasta que el flujo reanudado ya no dependa de ellas y se haya verificado el destino.

¿Cómo se verifica la réplica final?

Compare la ascendencia GUID de las instantáneas, las propiedades, los archivos esperados y una muestra de restauración, no solo el estado de salida del comando.

Para la replicación reanudable de ZFS, la respuesta práctica sigue siendo condicional: el flujo de reanudación se completa y las instantáneas de origen y destino comparten la ascendencia GUID esperada. Cuando no existe ningún token, el destino se revirtió o se eliminaron las instantáneas de origen necesarias, cancele la recepción parcial solo después de decidir que el coste del reinicio es aceptable; un éxito parcial que no puede resistir la carga de trabajo original no es compatibilidad.