Copia de seguridad y migración de volúmenes Docker: guía práctica con 3 métodos

El año pasado, en el Singles’ Day, la empresa migró servidores de Alibaba Cloud a Tencent Cloud. Cuando el jefe preguntó qué hacer con los datos de la base de datos en Docker — un contenedor PostgreSQL llevaba meses en ejecución con varios GB de datos de usuario, sin ninguna copia de seguridad — la respuesta no era obvia.

Esa noche busqué a toda prisa métodos de respaldo en Docker y leí montones de tutoriales. docker cp, empaquetado con tar, herramientas como docker-volume-backup… Cuanto más leía, más confuso estaba. Cada método parecía correcto, pero no sabía cuál usar ni me atrevía a probarlo en producción. Lo que más miedo daba era respaldar mientras la base de datos escribía datos y acabar con un archivo corrupto.

Después de tropezar varias veces, fui entendiendo cómo funciona. En realidad, respaldar datos en Docker no es tan complicado; la clave es saber qué método encaja en cada escenario. En este artículo repaso 3 métodos habituales: cuándo usar cada uno, cómo hacerlo y qué trampas evitar. Al terminar sabrás cómo montar un respaldo fiable para tu aplicación Docker.

Por qué importa respaldar datos en Docker

Cómo se almacenan los datos en Docker

Mucha gente, al empezar con Docker, no presta atención al almacenamiento. Arrancas el contenedor, los datos están ahí y todo parece bien. Pero hay un detalle que muchos pasan por alto: los contenedores son efímeros.

Si escribes datos directamente dentro del contenedor, al reiniciarlo o actualizar la imagen los pierdes. Por eso Docker ofrece dos formas de persistir datos:

• Volume (volumen): almacenamiento gestionado por Docker, guardado en /var/lib/docker/volumes/. Es la opción recomendada; Docker gestiona permisos y ciclo de vida.
• Bind Mount (montaje de directorio): montas un directorio del host dentro del contenedor. Por ejemplo, montas /home/user/data en /data del contenedor; los datos quedan donde los conoces y puedes respaldarlos con un simple cp.

Qué datos conviene respaldar, en mi experiencia:

• Archivos de bases de datos (directorios de datos de PostgreSQL, MySQL, MongoDB)
• Archivos subidos por usuarios (avatares, documentos, imágenes)
• Archivos de configuración (aunque mucha config se puede reconstruir, conviene respaldar la sensible)
• Archivos de log (si necesitas analizar historial)

Escenarios habituales de pérdida de datos

Los incidentes que he visto o escuchado suelen encajar en estos casos:

Borrar un contenedor por error. Es lo más frecuente. Quieres eliminar un contenedor de prueba y ejecutas docker rm -v, que borra también los volúmenes anónimos asociados. Ese -v es el culpable. La primera vez que lo usé sin saberlo, perdí la base de datos del entorno de prueba.

Fallo de disco. Un servidor lleva dos o tres años y de repente SMART avisa; hay que cambiar el disco. A veces aún se pueden leer los datos, pero el susto es real. Con respaldos periódicos, aunque falle el disco, restauras en minutos.

Migración de servidor. Ya lo conté al inicio. Cambiar de datacenter, de proveedor cloud o pasar de VPS a Kubernetes: mover los datos es un problema serio. Sin respaldo, solo puedes rezar para que scp no se corte a mitad.

Otro caso real: el año pasado, una startup de un amigo perdió su contenedor de base de datos sin saber por qué. Al reiniciar, los datos del volumen estaban corruptos y PostgreSQL no arrancaba. El respaldo más reciente era de hace dos meses. Dos meses de pedidos perdidos; pérdidas de decenas de miles de yuanes.

No lo cuento para asustarte, sino para dejar claro: las copias de seguridad periódicas importan de verdad. Si pierdes los datos, ninguna técnica los devuelve.

3 métodos de respaldo explicados

Método 1: respaldo con tar (⭐⭐⭐⭐⭐ recomendado)

Es el que más uso; encaja en casi cualquier escenario. La idea es simple: montar el volumen en un contenedor temporal y empaquetarlo con tar.

Comando de respaldo:

docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/postgres-backup-20251217.tar.gz -C /data .

Desglose del comando:

• --rm: el contenedor se elimina al terminar, sin basura
• -v postgres_data:/data:ro: monta el volumen a respaldar (postgres_data) en /data del contenedor; :ro es solo lectura, para evitar cambios accidentales
• -v $(pwd):/backup: monta el directorio actual en /backup; ahí se guarda el archivo
• tar czf: c crea archivo, z comprime con gzip, f indica nombre de archivo
• -C /data .: entra en /data y empaqueta todo (. = directorio actual)

Comando de restauración:

docker run --rm \
  -v postgres_data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/postgres-backup-20251217.tar.gz -C /data

Aquí x descomprime; el resto es similar al respaldo.

¿Cuándo usar este método?

• Sirve para cualquier tipo de volumen; es el más universal
• Necesitas compresión para ahorrar espacio (30-50 % de reducción)
• Quieres transferir el respaldo a otro servidor o almacenamiento en la nube

Precauciones:

La primera vez cometí un error: respaldé un MySQL en ejecución. El respaldo funcionó, pero al restaurar la base de datos no arrancaba por tablas corruptas. Después supe que si la base de datos escribe durante el respaldo, puedes capturar un estado inconsistente.

Lo más seguro:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

1. Detener escrituras (parar contenedor o bloquear tablas)
2. Ejecutar el respaldo
3. Reanudar escrituras

Si no puedes parar el servicio, al menos asegúrate de tener journal o WAL activos; así la base de datos puede repararse tras restaurar.

Caso práctico: respaldar PostgreSQL

# 1. Detener el contenedor PostgreSQL (si puedes)
docker stop my-postgres

# 2. Respaldar el volumen
docker run --rm \
  -v postgres_data:/data:ro \
  -v /backup:/backup \
  ubuntu tar czf /backup/pg-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

# 3. Verificar el archivo de respaldo
ls -lh /backup/pg-*.tar.gz

# 4. Reiniciar el contenedor
docker start my-postgres

En el nombre suelo añadir timestamp para ver de un vistazo cuándo se hizo el respaldo.

Método 2: comando docker cp (⭐⭐⭐)

Más directo: sin empaquetar, copias los archivos tal cual. Ideal para respaldos rápidos de pocos archivos de configuración o directorios pequeños.

Pasos de respaldo:

# 1. Crear un contenedor temporal asociado al volumen
docker create -v nginx_config:/data --name temp_backup busybox

# 2. Copiar datos al host
docker cp temp_backup:/data ./nginx-config-backup

# 3. Limpiar el contenedor temporal
docker rm temp_backup

Pasos de restauración:

# Suponiendo que restauras en un contenedor nuevo
docker cp ./nginx-config-backup/. my-nginx:/etc/nginx/

¿Cuándo usar este método?

• Solo necesitas respaldar unos pocos archivos de configuración
• Los archivos son pequeños (decenas de MB como mucho)
• Quieres ver el contenido del respaldo sin descomprimir

Desventajas:

• Sin compresión; ocupa más espacio con archivos grandes
• Transferencia algo más lenta que tar
• No conserva perfectamente todos los permisos y atributos especiales

Caso práctico: respaldar configuración de Nginx

# Crear contenedor temporal
docker create -v nginx_config:/config --name nginx_temp busybox

# Copiar archivo de configuración
docker cp nginx_temp:/config/nginx.conf ./backup/

# También puedes copiar el directorio completo
docker cp nginx_temp:/config/. ./backup/nginx-config/

# Limpiar
docker rm nginx_temp

Suelo usarlo para configuraciones. Antes de tocar Nginx, hago un docker cp; si algo sale mal, restauro rápido.

Método 3: herramienta docker-volume-backup (⭐⭐⭐⭐ preferida para automatización)

Los dos métodos anteriores son manuales, bien para respaldos puntuales. En producción quieres respaldos programados automáticamente; ahí entran las herramientas.

Yo uso offen/docker-volume-backup, una opción open source muy usada en 2025. Sus ventajas:

• Respaldos automáticos programados (expresión cron)
• Detiene contenedores antes del respaldo para consistencia
• Varios backends (S3, Google Drive, SSH, WebDAV)
• Limpieza automática de respaldos antiguos

Ejemplo de Docker Compose:

version: '3.8'

services:
  # Tu servicio de base de datos
  postgres:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    labels:
      # Marca que este contenedor debe detenerse durante el respaldo
      - "docker-volume-backup.stop-during-backup=true"

  # Servicio de respaldo
  backup:
    image: offen/docker-volume-backup:latest
    environment:
      # Respaldo diario a las 2:00
      BACKUP_CRON_EXPRESSION: "0 2 * * *"
      # Nombre del archivo de respaldo
      BACKUP_FILENAME: "db-backup-%Y%m%d-%H%M%S.tar.gz"
      # Conservar respaldos de los últimos 7 días
      BACKUP_RETENTION_DAYS: "7"
    volumes:
      # Volumen a respaldar (solo lectura)
      - db_data:/backup/db_data:ro
      # Destino de los respaldos
      - ./backups:/archive
      # Necesario montar Docker socket para detener contenedores
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  db_data:

Flujo de trabajo:

1. Cada día a las 2:00 arranca el contenedor de respaldo
2. Detecta la etiqueta stop-during-backup en postgres y lo detiene
3. Empaqueta el volumen db_data con tar
4. Guarda el archivo en ./backups
5. Reinicia postgres
6. Elimina respaldos de más de 7 días

¿Cuándo usar este método?

• Producción con respaldos periódicos automáticos
• Quieres subir respaldos a almacenamiento en la nube (S3, GCS, etc.)
• Gestionas respaldos de varios contenedores

Precauciones:

Al configurarlo por primera vez, cuida los permisos. El contenedor de respaldo debe poder leer /var/run/docker.sock para detener otros contenedores.

Además, la herramienta detiene tu servicio unos segundos o decenas de segundos (según el volumen de datos). Si no puedes parar el servicio, no uses la etiqueta stop-during-backup, pero asume el riesgo de un respaldo inconsistente.

Caso práctico: respaldo automático de MongoDB

version: '3.8'

services:
  mongodb:
    image: mongo:7
    volumes:
      - mongo_data:/data/db
    labels:
      - "docker-volume-backup.stop-during-backup=true"

  backup:
    image: offen/docker-volume-backup:latest
    environment:
      BACKUP_CRON_EXPRESSION: "0 3 * * *"
      BACKUP_FILENAME: "mongo-%Y%m%d.tar.gz"
      BACKUP_RETENTION_DAYS: "14"
      # Subir respaldo a AWS S3
      AWS_S3_BUCKET_NAME: "my-backups"
      AWS_ACCESS_KEY_ID: "${AWS_KEY}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET}"
    volumes:
      - mongo_data:/backup/mongo_data:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  mongo_data:

Esta configuración respalda MongoDB cada día a las 3:00 y sube el archivo a S3, sin conservarlo en local. La llevo más de medio año y va estable.

Flujo completo de migración de datos

Pasos prácticos para migrar un servidor

Tras los métodos de respaldo, el flujo real de migración. El año pasado migré de Alibaba Cloud a Tencent Cloud; el proceso fue más o menos así:

1. Fase de preparación (no la saltes)

Primero, entiende el entorno actual:

# Listar todos los contenedores
docker ps -a

# Listar todos los volúmenes
docker volume ls

# Exportar la configuración de cada contenedor (¡importante!)
docker inspect my-postgres > postgres-config.json
docker inspect my-nginx > nginx-config.json

# Guardar docker-compose.yml y .env
cp docker-compose.yml docker-compose.backup.yml
cp .env .env.backup

Esos archivos de configuración hay que guardarlos bien. En mi primera migración olvidé las variables de entorno; en el nuevo servidor la contraseña de la base de datos no coincidía y perdí un buen rato.

2. Fase de respaldo

Para todo y respalda:

# Detener todos los contenedores
docker-compose down

# Respaldar cada volumen
docker run --rm \
  -v postgres_data:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/postgres_data.tar.gz -C /data .

docker run --rm \
  -v nginx_config:/data:ro \
  -v $(pwd)/backups:/backup \
  ubuntu tar czf /backup/nginx_config.tar.gz -C /data .

# Verificar archivos de respaldo
ls -lh backups/
md5sum backups/*.tar.gz > backups/checksums.txt

Ese md5sum importa. Si la red inestabiliza la transferencia y corrompe un archivo, al menos lo detectas.

3. Fase de migración

Transfiere los respaldos al nuevo servidor:

# Suelo usar rsync, con reanudación
rsync -avP --partial backups/ user@new-server:/tmp/backups/

# O con scp
scp -r backups/ user@new-server:/tmp/backups/

Si los archivos son muy grandes (decenas de GB) y la red es mala, conviene un almacenamiento de objetos intermedio: sube a S3 u OSS y descarga desde el nuevo servidor; suele ser más rápido y fiable.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Restaurar en el nuevo servidor:

# 1. Crear volúmenes
docker volume create postgres_data
docker volume create nginx_config

# 2. Restaurar datos
docker run --rm \
  -v postgres_data:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/postgres_data.tar.gz -C /data

docker run --rm \
  -v nginx_config:/data \
  -v /tmp/backups:/backup \
  ubuntu tar xzf /backup/nginx_config.tar.gz -C /data

# 3. Verificar datos restaurados
docker run --rm -v postgres_data:/data ubuntu ls -lh /data

# 4. Arrancar servicios
docker-compose up -d

4. Fase de verificación

Tras arrancar, no cambies el tráfico de inmediato. Verifica:

# Estado de contenedores
docker ps

# Logs, sin errores
docker-compose logs -f

# Probar conexión a la base de datos
docker exec -it my-postgres psql -U postgres -c "SELECT COUNT(*) FROM users;"

# Comparar datos entre servidores
# (suelo usar un script que compare conteos de tablas clave)

Cuando todo cuadra, cambia DNS o el balanceador y enruta el tráfico.

Trampas que he pisado:

En la migración del año pasado, un volumen pesaba 50 GB; descomprimir con docker run tar tardó casi una hora. Luego descubrí que puedes crear el volumen con docker volume create y descomprimir directamente en /var/lib/docker/volumes/volume_name/_data en el host; va mucho más rápido. Ojo con los permisos.

Precauciones especiales para respaldo de bases de datos

El respaldo de bases de datos es un pozo aparte.

¿Por qué no basta un respaldo a nivel de archivos?

Piénsalo: con la base de datos en ejecución, los datos se escriben constantemente. InnoDB en MySQL tiene redo log y undo log; PostgreSQL tiene WAL; todo para consistencia transaccional. Si empaquetas los archivos con tar a mitad de una transacción, el respaldo puede quedar inconsistente.

El peor caso que vi: alguien respaldó MySQL justo durante una transacción grande (millones de inserciones). El archivo parecía bien, pero tras restaurar MySQL no arrancaba por corrupción del tablespace InnoDB.

Enfoque correcto: respaldo a nivel de aplicación

PostgreSQL:

# Respaldar una base de datos
docker exec my-postgres pg_dump -U postgres mydb > mydb-backup.sql

# Respaldar todas las bases de datos
docker exec my-postgres pg_dumpall -U postgres > all-dbs-backup.sql

# Restaurar
docker exec -i my-postgres psql -U postgres mydb < mydb-backup.sql

MySQL:

# Respaldo
docker exec my-mysql mysqldump -u root -p mydb > mydb-backup.sql

# Restauración
docker exec -i my-mysql mysql -u root -p mydb < mydb-backup.sql

MongoDB:

# Respaldo
docker exec my-mongo mongodump --out=/backup
docker cp my-mongo:/backup ./mongo-backup

# Restauración
docker cp ./mongo-backup my-mongo:/backup
docker exec my-mongo mongorestore /backup

Estrategia de doble seguridad:

Lo que hago ahora: respaldo a nivel de aplicación + respaldo de volumen.

• Aplicación (pg_dump, etc.): recuperación principal con consistencia garantizada
• Volumen (tar): plan B ante desastre; si falla el respaldo lógico, aún tienes archivos

Ocupa más espacio, pero da tranquilidad. La startup que perdió datos solo tenía respaldo de volumen; al restaurar estaba corrupto y no habían hecho respaldo lógico.

Buenas prácticas y guía para evitar errores

Diseño de la estrategia de respaldo

Tener métodos no basta; hace falta una estrategia razonable. Si respaldas demasiado, gastas recursos; si poco, pierdes datos.

Regla 3-2-1 (estándar del sector):

• 3 copias: datos originales + 2 respaldos
• 2 medios distintos: por ejemplo disco local + nube, o dos discos diferentes
• 1 copia off-site: al menos un respaldo en otra ubicación (incendio, terremoto, etc.)

Suena complejo, pero en la práctica:

• Servidor local: respaldos diarios de los últimos 7 días (copia 1)
• NAS: respaldos de los últimos 30 días (copia 2, otro medio)
• S3: respaldos mensuales de los últimos 3 meses (copia 3, off-site)

Frecuencia recomendada:

Convención de nombres:

Un buen nombre evita locura al restaurar. Mi formato:

<nombre-servicio>-<tipo-dato>-<YYYYMMDD>-<HHMMSS>.tar.gz

Ejemplos:

myapp-postgres-20251217-020000.tar.gz
myapp-nginx-config-20251217-020000.tar.gz
myapp-uploads-20251217-020000.tar.gz

Así se ordenan por fecha y ves de un vistazo qué es cada respaldo.

Problemas frecuentes y soluciones

Problema 1: «volume is in use» al respaldar

En general no aparece, porque un volumen puede montarse en varios contenedores. Si lo ves, puede deberse a:

• Bloqueo de archivos en el contenedor
• Montaje NFS u otro almacenamiento en red

Solución:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

# Ver qué contenedores usan el volumen
docker ps --filter volume=my_volume

# Si puedes, detener esos contenedores
docker stop container_name

# O usar --volumes-from
docker run --rm --volumes-from=my_container -v $(pwd):/backup ubuntu tar czf /backup/data.tar.gz -C /data .

Problema 2: permisos incorrectos tras restaurar

También me pasó. tar suele conservar permisos, pero entre sistemas distintos (Ubuntu y CentOS, por ejemplo) UID/GID pueden no coincidir.

Síntoma: el contenedor arranca con error de permisos de lectura/escritura.

Solución:

# Especificar owner al restaurar
docker run --rm -v my_volume:/data -v $(pwd):/backup ubuntu sh -c "tar xzf /backup/data.tar.gz -C /data && chown -R 999:999 /data"

# 999:999 es el UID del usuario postgres en el contenedor PostgreSQL
# Cada imagen tiene UID distinto; consulta documentación o docker inspect

Problema 3: archivo de respaldo demasiado grande para transferir

Una vez respaldé MySQL de 50 GB; comprimido con gzip seguían siendo 30 GB. Por internet iba lentísimo y se cortaba a menudo.

Soluciones:

1. Mayor compresión: xz comprime 20-30 % más que gzip, más lento

   tar cJf backup.tar.xz /data  # J = compresión xz
   

2. Archivos divididos: útil con límites de tamaño

   tar czf - /data | split -b 1G - backup.tar.gz.
   # Restaurar: cat backup.tar.gz.* | tar xzf -
   

3. Respaldo incremental: solo archivos cambiados (rsync u otras herramientas)

Problema 4: respaldo corrupto al restaurar

Lo peor: no lo notas al respaldar y lo descubres cuando lo necesitas.

Prevención:

# Verificar justo después del respaldo
md5sum backup.tar.gz > backup.tar.gz.md5

# Verificar de nuevo tras transferir al nuevo servidor
md5sum -c backup.tar.gz.md5

# Probar restauración con regularidad (¡lo más importante!)
# Cada mes, en un entorno de prueba, restaura un respaldo real

Mi hábito: tras cada respaldo, descomprimo unos archivos para comprobar que el archivo está íntegro.

Automatización y monitorización

El respaldo manual es fiable, pero la gente olvida. En producción hay que automatizar.

Crontab para ejecutar script de respaldo:

# Script /opt/scripts/backup-docker-volumes.sh
#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=/backup

# Respaldar PostgreSQL
docker run --rm \
  -v postgres_data:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/postgres-$DATE.tar.gz -C /data .

# Respaldar configuración Nginx
docker run --rm \
  -v nginx_config:/data:ro \
  -v $BACKUP_DIR:/backup \
  ubuntu tar czf /backup/nginx-$DATE.tar.gz -C /data .

# Eliminar respaldos de más de 7 días
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

# Notificación opcional
echo "Backup completed: $DATE" | mail -s "Docker Backup Report" [email protected]

# Añadir a crontab
crontab -e

# Ejecutar cada día a las 2:00
0 2 * * * /opt/scripts/backup-docker-volumes.sh >> /var/log/docker-backup.log 2>&1

Monitorización y alertas:

Automatizar no basta; hay que saber si el respaldo tuvo éxito. Lo que hago:

1. Registrar logs: cada respaldo con hora, tamaño y MD5
2. Script de comprobación: cada día verificar que hay respaldo nuevo; si no, alertar
3. Detección de tamaño anómalo: si el archivo crece o encoge mucho (>50 % de la media), puede haber problema

Script de monitorización simple:

#!/bin/bash
BACKUP_DIR=/backup
EXPECTED_SIZE=100000000  # 100 MB, ajusta según tu caso

LATEST_BACKUP=$(ls -t $BACKUP_DIR/postgres-*.tar.gz | head -1)
if [ -z "$LATEST_BACKUP" ]; then
  echo "ERROR: No backup file found!"
  exit 1
fi

# Comprobar si el respaldo es de hoy
BACKUP_DATE=$(stat -c %Y "$LATEST_BACKUP")
TODAY=$(date +%s)
AGE=$((TODAY - BACKUP_DATE))

if [ $AGE -gt 86400 ]; then
  echo "ERROR: Latest backup is older than 24 hours!"
  exit 1
fi

# Comprobar tamaño
SIZE=$(stat -c %s "$LATEST_BACKUP")
if [ $SIZE -lt $(($EXPECTED_SIZE / 2)) ]; then
  echo "WARNING: Backup file is too small: $SIZE bytes"
  exit 1
fi

echo "Backup check passed: $LATEST_BACKUP ($SIZE bytes)"

Estos scripts pueden integrarse en Prometheus, Zabbix, etc., o enviar correo o notificaciones de equipo.

Conclusión

Volviendo a la pregunta inicial: ¿cómo respaldar datos en Docker?

La respuesta es sencilla: ningún método sirve para todo; elige según tu escenario.

• Respaldo puntual o migración rápida: tar, universal y fiable
• Configuraciones y archivos pequeños: docker cp, directo
• Producción con automatización: docker-volume-backup, menos trabajo manual

Y lo más importante: respaldar con regularidad y probar la restauración. No esperes a necesitar los datos para descubrir que el archivo está corrupto o no se puede restaurar. Cada mes restauro el último respaldo en un entorno de prueba para validar el flujo.

Un consejo: haz hoy la primera copia de seguridad de tu aplicación Docker. No hace falta complicarse; prueba el método tar más simple. Con el archivo en disco, te quedas mucho más tranquilo.

Si tienes problemas al respaldar o conoces mejores métodos, comenta abajo. Compartir experiencias ayuda a evitar errores.