¿Por qué se atasca una copia de seguridad de Restic cuando otro host comienza a depurar?
La copia de seguridad suele bloquearse porque la poda necesita el control exclusivo del repositorio compartido, por lo que el segundo host no puede continuar con el mismo estado del repositorio en ese momento.
En una configuración doméstica con varios hosts, el momento en que ocurre es el mejor primer indicador: la copia de seguridad avanza con normalidad, otra máquina inicia la poda y, a continuación, la copia de seguridad espera o informa de un bloqueo. Confirma el propietario del bloqueo y el registro de mantenimiento activo antes de hacer nada. Deja que la poda termine o detenla correctamente desde el host propietario; nunca elimines su bloqueo desde el cliente de copia de seguridad que está esperando.
Confirma que la poda es el desencadenante exacto
Guarda el registro de la copia de seguridad en espera y el registro de mantenimiento del host que ejecuta la poda, ambos con sus marcas de tiempo. Enumera los bloqueos del repositorio y relaciona el host, el proceso y el estado exclusivo con el trabajo de poda. La causa queda respaldada cuando el avance de la copia de seguridad se detiene después de que la poda adquiere el repositorio y se reanuda después de liberar ese bloqueo.
Los operadores que utilizan un repositorio desde varios hosts informan de contención de bloqueos durante la poda porque la operación de mantenimiento compite con programaciones de copia de seguridad que, por lo demás, son independientes.
Si la copia de seguridad ya era lenta, el host de poda nunca obtuvo un bloqueo o ambos registros se detienen por un error de almacenamiento, no fuerces este diagnóstico. Comprueba la disponibilidad y la latencia del backend, así como el propio proceso de copia de seguridad. La explicación del bloqueo de poda solo se aplica cuando coinciden el desencadenante, el propietario del bloqueo y el momento de liberación.
Trata el bloqueo exclusivo como un límite de seguridad
La poda modifica el almacenamiento del repositorio y, por tanto, necesita una vista coherente mientras trabaja. La copia de seguridad en espera no está necesariamente bloqueada en el sentido habitual del proceso; puede estar respetando el bloqueo de mantenimiento. La primera pregunta es si la poda está avanzando, no cómo hacer que la copia de seguridad ignore el bloqueo.
Un diseño con repositorio compartido necesita un único responsable del mantenimiento porque el mantenimiento de todo el repositorio afecta a todos los clientes, incluso cuando los datos de origen pertenecen a hosts diferentes.
Si los registros de poda avanzan y continúa la E/S del repositorio, deja el bloqueo en su sitio y permite que el trabajo termine. Si el trabajo está realmente atascado, detenlo correctamente desde el host que lo posee y espera a que finalice de forma limpia. Eliminar el bloqueo desde otro cliente mientras la poda sigue escribiendo convierte una espera controlada en una operación simultánea insegura.
Recupera la copia de seguridad en espera sin omitir el bloqueo
La solución menos invasiva es esperar a que termine la poda. Si la copia de seguridad tiene una política de reintentos limitada, deja que vuelva a intentarlo después de que desaparezca el bloqueo exclusivo. Cuando sea necesario detener la poda, utiliza el gestor de servicios o el supervisor de procesos del host propietario, espera a que se apague y confirma que la lista de bloqueos ha cambiado antes de reiniciar la copia de seguridad.
La retención puede estar delimitada por host, pero la reclamación física de espacio sigue siendo una tarea del repositorio. Una política de retención delimitada por host evita seleccionar las instantáneas equivocadas; no hace que la poda simultánea sea segura para clientes de copia de seguridad no relacionados.
Reintenta la copia de seguridad en espera utilizando el bloqueo normal. Si termina, la reparación coincide con la causa confirmada. Si otra poda se inicia de inmediato, desactiva la programación de mantenimiento duplicada. Si la copia de seguridad sigue bloqueándose sin un bloqueo exclusivo, deja de aumentar los reintentos y vuelve al diagnóstico del backend, la red, el escaneo del origen o el proceso.
Vuelve a probar la superposición original y define el límite
Utiliza una ventana controlada con registros completos. Inicia una copia de seguridad normal, invoca después el controlador de mantenimiento previsto y confirma que no crea una superposición insegura. Repite el procedimiento en el orden previsto, primero con la poda, y verifica que la copia de seguridad espera o finaliza según la política configurada y que después se completa cuando se libera el bloqueo.
Si una poda interrumpida deja el repositorio en un estado operativo diferente, sigue el diagnóstico de la poda interrumpida en lugar de tratar cada fallo posterior como una contención normal.
La recuperación es satisfactoria cuando la superposición original se gestiona de forma predecible, la copia de seguridad termina posteriormente, la poda finaliza correctamente y una instantánea de muestra puede restaurarse. Escala el caso si el bloqueo nunca se actualiza o libera, varios hosts siguen iniciando tareas de mantenimiento o una comprobación del repositorio informa de daños. Esos resultados exceden la causa única de una poda activa.
Productos recomendados
Soporte y Consejos
Más para leer
Cómo programar tareas de copia de seguridad, olvido y depuración de Restic sin conflictos de bloqueo
Una programación completa de Restic para varios hosts que separa las copias de seguridad frecuentes, la retención delimitada, la depuración física, las comprobaciones, los...
Cómo evitar que los trabajos de depuración de Restic bloqueen las copias de seguridad programadas
Un plan de prevención para repositorios Restic compartidos que separe las ventanas de copia de seguridad de la poda y mantenga intactos el bloqueo,...
Cómo eliminar un bloqueo obsoleto de Restic sin interrumpir una copia de seguridad activa
Un flujo de desbloqueo de Restic mínimamente invasivo que protege las copias de seguridad activas, elimina únicamente el estado obsoleto y confirma la recuperación...
