¿Cuándo debería volver a sembrar una cadena de replicación ZFS interrumpida?

Vuelve a sembrar cuando no puedas demostrar que existe una base común válida o cuando reparar la cadena requiera una reversión no verificada del destino. Conserva primero la última réplica legible.

En un NAS doméstico, el atajo tentador es forzar el siguiente envío incremental hasta que se ejecute. Eso puede ocultar una instantánea principal ausente, un destino divergente o un objetivo de recepción que ya no sea el conjunto de datos que crees. Empieza inventariando ambos lados sin modificar ninguno, demuestra si todavía existe una base compartida y utiliza una siembra completa por etapas cuando las pruebas no respalden una continuación incremental segura.

Demuestra que ambos lados todavía comparten la misma base

Comienza con un inventario de solo lectura del conjunto de datos de origen, el conjunto de datos de destino, las instantáneas, los marcadores y cualquier estado de reanudación de recepción. Comprueba más que un nombre de instantánea conveniente: confirma que la base candidata pertenece a los conjuntos de datos previstos y representa el mismo historial de replicación. Guarda los listados antes de la limpieza para poder explicar por qué elegiste la siguiente acción.

La replicación incremental de ZFS depende de que el receptor ya tenga una base. Por ello, una secuencia de replicación de instantáneas práctica conserva deliberadamente el historial compartido en lugar de asumir que las etiquetas idénticas demuestran continuidad.

Si existe una base verificada en ambos lados, continúa con una prueba incremental no destructiva. Si el nombre existe, pero la identidad o la ruta del conjunto de datos difieren, considera que la cadena no está demostrada. Si ya no queda ninguna base común, no elimines más instantáneas ni fuerces el destino hacia atrás; la decisión ya se ha orientado hacia una resiembra por etapas.

Prueba el plan incremental sin modificar la réplica

Construye el envío propuesto con la base verificada y el destino más reciente, pero no lo canalices todavía al destino activo. Utiliza una ejecución de prueba, una estimación detallada o el modo de vista previa de la herramienta de replicación. Confirma la ruta de origen, la ruta de destino, la instantánea base, la instantánea objetivo, las opciones de recursión y el tamaño esperado del flujo antes de que cualquier recepción pueda modificar los datos.

Un programador que informa de ninguna instantánea base común está rechazando una suposición insegura, no solicitando simplemente otro intento. Los reintentos repetidos no recrean el historial compartido eliminado.

Un flujo del tamaño del delta desde la base y el destino exactos respalda la reparación de la cadena. Un flujo cercano al tamaño completo del conjunto de datos, un conjunto de datos inesperado o cualquier requisito de reversión forzada significa que la vista previa falló. Detente ahí y conserva la réplica actual; cambiar opciones hasta que el comando se ejecute no es una verificación.

Elige reparar solo cuando el historial y el estado del destino coincidan

Repara la ruta incremental únicamente cuando la base común esté verificada, el destino no se haya convertido en una copia de trabajo independiente y la vista previa proponga el delta esperado. Mantén el destino en modo de solo lectura durante la ventana de reparación. Envía primero a un conjunto de datos hijo nuevo o a un destino de preparación cuando la herramienta lo permita y, después, compáralo antes de promocionarlo.

Vuelve a sembrar cuando no exista una base válida, el destino haya divergido, la reversión necesaria descartaría instantáneas que todavía necesitas o el tiempo dedicado a demostrar la cadena supere el coste controlado de una nueva transferencia completa. Los análisis sobre la ascendencia de las instantáneas incrementales refuerzan que los nombres intermedios son menos importantes que conservar un punto común utilizable.

No borres el destino antiguo para liberar espacio a menos que exista otra copia verificada. Una resiembra más segura escribe en un conjunto de datos o grupo de almacenamiento independiente, verifica la copia nueva y solo entonces retira la cadena dañada. Si no hay capacidad suficiente para conservar ambas, detente y consigue espacio temporal en lugar de convertir la última réplica legible en el experimento.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valida la nueva cadena en dos ciclos de replicación

Una recepción completa correcta solo demuestra que llegó un flujo. Crea un archivo de prueba pequeño o cambia una propiedad en el origen, toma la siguiente instantánea programada y ejecuta un segundo ciclo incremental usando la nueva base común. Compara las propiedades de los conjuntos de datos, las listas de instantáneas, una muestra de archivos y el registro de replicación después de ambas ejecuciones.

Si el comportamiento de reanudación formaba parte del fallo original, mantén la ruta del fallo del token de reanudación separada de la ascendencia ausente para que el mismo síntoma no te devuelva a la reparación equivocada.

La recuperación se completa cuando la nueva semilla es legible, la segunda transferencia incremental tiene el tamaño del delta y finaliza correctamente, y las instantáneas y los archivos esperados aparecen después de un reinicio o de una ejecución programada. Conserva la réplica anterior hasta que esas comprobaciones se completen. Escala el problema si las identidades vuelven a cambiar, el destino no puede permanecer en modo de solo lectura o la herramienta selecciona repetidamente una base inesperada.