Flujo de migración de volúmenes con nombre de Docker entre dos servidores domésticos

El enfoque seguro consiste en tratar un archivo de reserva en estado inactivo o una copia sincronizada en un volumen de destino identificado explícitamente, seguida de la validación mediante suma de comprobación y de la aplicación, como una secuencia de controles observables, no como un solo comando.

En dos servidores domésticos Linux que ejecutan Docker Compose, el riesgo práctico es que un contenedor con estado deba trasladarse a otro host sin copiar un volumen activo o con un nombre incorrecto. Registra la identidad actual y el punto de recuperación, comienza con el discriminador menos invasivo, interpreta los resultados correctos e incorrectos antes de cambiar otra variable y detente cuando el almacenamiento se vuelva inestable o la única copia recuperable quede expuesta. El flujo de trabajo que se muestra a continuación solo termina cuando la carga de trabajo original funciona correctamente o las pruebas alcanzan un límite de escalamiento.

Identifica los contratos de los volúmenes de origen y destino

Registra el resumen de imagen del contenedor de origen, el nombre del proyecto de Compose, el servicio, la clave del volumen, el nombre real del volumen de Docker, el destino de montaje, el controlador del volumen y la versión de la aplicación. Usa docker inspect y docker volume inspect; no infieras la ruta física únicamente a partir de una etiqueta de YAML.

Compose normalmente antepone el nombre del proyecto a los volúmenes con nombre, a menos que se use un nombre explícito o un volumen externo. En el destino, representa la configuración de Compose y crea explícitamente el volumen vacío previsto para que la migración no termine en un volumen mientras el servicio inicia otro.

Si el volumen contiene una base de datos, usa su volcado nativo o una copia de seguridad compatible como ruta principal de recuperación portátil y trata la copia del volumen como un punto de recuperación para la misma versión. Detente si el controlador es remoto, el almacenamiento de origen es inestable o el estado de la aplicación abarca volúmenes adicionales que no están incluidos.

Detén las escrituras y crea una copia que conserve los metadatos

Pon la aplicación en modo de mantenimiento, detén los trabajos en segundo plano y, después, detén correctamente la aplicación y la base de datos. Confirma que ningún contenedor monte el volumen con permisos de lectura y escritura. Crea un archivo mediante un contenedor temporal o usa una copia controlada del sistema de archivos que conserve la propiedad numérica, los permisos, los enlaces simbólicos, los atributos extendidos cuando sean necesarios y los archivos dispersos.

La guía independiente sobre la migración de volúmenes de Docker con rsync muestra cómo trasladar datos de volúmenes de Docker con rsync. El límite importante es que el origen debe estar inactivo y el comando de copia debe operar sobre el contenido del volumen identificado, no manipular ciegamente el directorio interno de Docker mientras el demonio lo está utilizando.

Genera un manifiesto con el recuento de archivos, el total de bytes, hashes representativos y la suma de comprobación del archivo. Mantén intactos el volumen de origen y la copia de seguridad nativa; la etapa de copia solo se completa correctamente cuando el artefacto transferido se puede leer en el host de destino.

Restaura en el volumen de destino explícito

Verifica la capacidad del sistema de archivos de destino, la disponibilidad de inodos, las expectativas de UID y GID y la misma versión de la imagen de la aplicación. Restaura el archivo en el volumen de destino vacío sin aplanar la estructura de directorios de nivel superior y, después, compara la propiedad, los recuentos, los tamaños y algunos hashes.

Una conversación de la comunidad sobre un caso de fallo en la migración de un volumen con nombre muestra por qué reemplazar archivos directamente en las estructuras internas de los volúmenes de Docker puede fallar o dejar un estado confuso. Usa el entorno de ejecución para montar el volumen en un contenedor auxiliar y realizar la restauración mediante esa interfaz controlada.

Conecta primero solo una copia desechable del servicio, utilizando puertos alternativos y sin acceso a los pares de producción. Si la aplicación informa de actualizaciones del esquema o de un estado dañado, detente y vuelve a restaurar el volumen desde el artefacto sin modificar después de resolver la compatibilidad de versiones.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Realiza el cambio y conserva un host de reversión

Inicia las dependencias antes que la aplicación, verifica los registros, el inicio de sesión, los registros recientes, los archivos adjuntos, los trabajos programados y una escritura desechable. Reinicia la pila de destino y confirma que vuelve a conectar el mismo volumen con nombre. Actualiza el proxy o el DNS solo después de que estas comprobaciones sean correctas.

El artículo relacionado de ZimaSpace sobre la copia de seguridad coherente de datos de contenedores resulta útil si el destino se inicia vacío a pesar de que la copia se haya realizado correctamente. Compara el origen del montaje en el entorno de ejecución con el volumen previsto antes de volver a copiar los datos; repetir las copias en el destino equivocado solo añade ambigüedad.

Mantén detenida la aplicación de origen y el volumen antiguo en modo de solo lectura hasta que una nueva copia de seguridad y una prueba de restauración se completen correctamente en el destino. Revierte el cambio devolviendo el tráfico al origen sin modificar solo si no se aceptaron escrituras nuevas en el destino; de lo contrario, detente y concilia los datos deliberadamente.