Cómo mover volúmenes Docker entre servidores

Cuando trabajas con aplicaciones en contenedores, la persistencia de datos es un aspecto crítico. Los volúmenes Docker son la solución estándar para esto, desacoplando los datos del ciclo de vida del contenedor. Sin embargo, en algún momento necesitas mover esos volúmenes entre servidores, ya sea por una migración completa, un cambio de proveedor o para escalar tu infraestructura. Si estás evaluando cómo crecer, entender cuándo escalar verticalmente y cuándo añadir otro VPS es clave.

El proceso no es tan simple como copiar y pegar, porque los datos están vivos y la integridad es prioritaria. Mi enfoque siempre es minimizar el downtime y asegurar que cada bit se mueve correctamente.

El problema con la persistencia de datos en contenedores

La ventaja de Docker es su portabilidad, pero esa portabilidad se complica cuando hablamos de datos. Un contenedor se puede recrear fácilmente, pero la base de datos que usa o los archivos que guarda no. Ahí es donde entran los volúmenes, que almacenan esa información fuera del contenedor.

Si quieres entender más a fondo la diferencia, tengo un artículo sobre volúmenes Docker vs bind mounts que explica cuándo usar cada uno. La cuestión es que, al migrar un servidor, no solo mueves la configuración de Docker, sino también todos esos datos asociados a tus aplicaciones.

Cómo mover volúmenes Docker entre servidores con rsync

La herramienta que uso para mover volúmenes entre servidores es rsync. Permite sincronizar directorios de forma eficiente, copiando solo los cambios, lo que es vital para minimizar el tiempo de inactividad. Este método funciona tanto si el volumen está gestionado por Docker como si es un bind mount.

Primero, asegúrate de tener rsync instalado en ambos servidores y acceso SSH entre ellos.

El proceso implica tres pasos clave: una sincronización inicial, un breve parón de los contenedores y una sincronización final.

1. Sincronización inicial en caliente

Identifica la ruta física del volumen en el servidor de origen. Para un volumen gestionado por Docker, puedes usar docker volume inspect <nombre_del_volumen> y buscar la clave Mountpoint.

Ejecuta un rsync inicial desde el servidor de origen al de destino. Esto copiará la mayor parte de los datos mientras la aplicación sigue funcionando.

# En el servidor de origen
rsync -avzh /var/lib/docker/volumes/nombre_volumen/_data/ usuario@ip_servidor_destino:/ruta/destino/temporal/

Este comando copia recursivamente (-r), mantiene permisos y tiempos (-a), muestra progreso (-v), comprime (-z) y es legible para humanos (-h). La barra final en /nombre_volumen/_data/ es importante para copiar el contenido del directorio, no el directorio en sí.

2. Parar los contenedores y sincronización final

Cuando la sincronización inicial termine, es momento de parar los contenedores que usan el volumen en el servidor de origen. Este es el único momento de downtime real.

# En el servidor de origen
docker stop <nombre_contenedor_1> <nombre_contenedor_2>

Una vez que los contenedores estén parados, ejecuta rsync de nuevo. Esta vez, solo se transferirán los cambios que se hayan producido desde la sincronización inicial, que deberían ser mínimos.

# En el servidor de origen
rsync -avzh /var/lib/docker/volumes/nombre_volumen/_data/ usuario@ip_servidor_destino:/ruta/destino/temporal/

3. Crear el volumen y arrancar en el nuevo servidor

En el servidor de destino, crea el volumen Docker y, si es necesario, copia los datos sincronizados a su Mountpoint definitivo.

# En el servidor de destino
docker volume create nombre_volumen_nuevo
# Obtener la ruta del nuevo volumen
MOUNTPOINT=$(docker volume inspect nombre_volumen_nuevo --format '{{ .Mountpoint }}')
# Copiar los datos sincronizados a la ruta del nuevo volumen
rsync -avzh /ruta/destino/temporal/ "$MOUNTPOINT"/

Finalmente, configura tus contenedores en el nuevo servidor para que usen este nombre_volumen_nuevo y arráncalos.

# En el servidor de destino
docker start <nombre_contenedor_1> <nombre_contenedor_2>

Tradeoffs de la migración de volúmenes Docker

Mover datos siempre implica decisiones. Con este método ganas velocidad y fiabilidad, pero no es magia.

Lo que ganas:

Mínimo downtime: La aplicación solo está inactiva durante la sincronización delta final, que suele ser muy rápida.
Integridad de datos: rsync verifica la integridad de los archivos y solo transfiere lo necesario.
Flexibilidad: Funciona con cualquier tipo de volumen (gestionado o bind mount) y entre diferentes sistemas operativos Linux.

Lo que complicas:

Coordinación: Necesitas acceso y control sobre ambos servidores y los contenedores.
Espacio temporal: Requiere espacio suficiente en el servidor de destino para una copia temporal de los datos.
Permisos: Asegurarte de que los permisos de los archivos se mantienen correctamente entre servidores, especialmente si el usuario root no es el mismo.

Mi regla es siempre verificar los datos después de la migración. Un diff -r entre origen y destino, o simplemente arrancar la aplicación y comprobar su funcionamiento, es un paso que no me salto.

Este proceso de migración de volúmenes es fundamental en la gestión de infraestructuras en producción. Si necesitas una estrategia robusta para tus datos, te recomiendo leer sobre cómo usar rsync para backups externos desde un VPS. Y si estás planificando una mudanza de mayor envergadura, tengo una guía sobre cómo migrar un sitio web a otro servidor sin downtime que te puede ser útil. Asegurarte de tener backups automáticos en un VPS es siempre el primer paso antes de cualquier movimiento de este tipo.