Backup de Volúmenes Docker en VPS: Guía Práctica de Persistencia

Los volúmenes Docker son el punto donde la abstracción de contenedor se encuentra con la realidad del disco. El contenedor es descartable — lo reconstruyes a partir de la imagen en minutos. El volumen es donde vive el estado real: base de datos, uploads de usuarios, configuraciones persistentes. Perder un volumen es perder datos de producción.

A pesar de esto, el backup de volúmenes es la parte más descuidada del stack Docker. La mayoría de las VPS ejecutando aplicaciones containerizadas no tienen rutina de backup configurada, solo la falsa seguridad de que “está todo en un contenedor”. Cuando el disco falla o alguien ejecuta docker volume prune distraído, la pérdida es definitiva.

Este tutorial muestra estrategias prácticas para hacer backup de volúmenes Docker en VPS Linux, cubriendo datos estáticos, bases de datos, y automatización con cron. Tiempo estimado de ejecución: 25-40 minutos para configurar el primer backup y validar la restauración.

Prerrequisitos

Confirma la versión de Docker y lista tus volúmenes antes de empezar:

docker --version
docker volume ls

Identificando volúmenes y contenedores afectados

Antes de hacer backup, mapea qué contenedores usan cada volumen. Backup ciego sin entender las dependencias causa inconsistencia — puedes capturar el archivo de base de datos en medio de una transacción si el contenedor está escribiendo.

docker volume ls --format '{{.Name}}'

docker ps -a --filter volume=nombre_del_volumen --format '{{.Names}}: {{.Image}}'

docker volume inspect nombre_del_volumen

sudo du -sh /var/lib/docker/volumes/nombre_del_volumen/_data

Backup de datos estáticos con tar

Los datos estáticos — uploads de usuario, configs, assets — pueden copiarse con el contenedor en ejecución. El riesgo de inconsistencia es bajo porque las escrituras atómicas (mv, rename) preservan el estado anterior hasta que la operación se complete.

La estrategia estándar usa un contenedor temporal Alpine con el volumen montado en modo solo-lectura, creando el tarball hacia un directorio del host.

sudo mkdir -p /var/backups/docker-volumes
sudo chmod 700 /var/backups/docker-volumes

docker run --rm \
  -v nombre_del_volumen:/source:ro \
  -v /var/backups/docker-volumes:/backup \
  alpine \
  tar czf /backup/volume-$(date +%Y%m%d-%H%M%S).tar.gz -C /source .

Backup consistente de bases de datos

Las bases de datos son el caso más delicado. Copiar los archivos binarios (datadir de MySQL, base/ de PostgreSQL) con el motor en ejecución resulta en backup corrupto — escrituras en curso, WAL no-flushed, índices inconsistentes. La solución es usar el dump nativo del motor.

docker exec nombre_contenedor_mysql \
  sh -c 'mysqldump --single-transaction --quick \
    -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' \
  | gzip > /var/backups/docker-volumes/mysql-$(date +%Y%m%d-%H%M%S).sql.gz

docker exec nombre_contenedor_pg \
  pg_dumpall -U postgres \
  | gzip > /var/backups/docker-volumes/postgres-$(date +%Y%m%d-%H%M%S).sql.gz

docker exec nombre_contenedor_mongo \
  mongodump --archive --gzip \
  > /var/backups/docker-volumes/mongo-$(date +%Y%m%d-%H%M%S).archive.gz

Automatización con cron

El backup manual no escala — lo olvidas, o lo haces solo cuando te acuerdas (generalmente cuando necesitas restaurar). Cron resuelve esto. La receta a continuación crea un script encapsulando la rutina y agenda ejecución diaria.

#!/bin/bash
set -euo pipefail

BACKUP_DIR=/var/backups/docker-volumes
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=14

# Backup MySQL
docker exec mysql_container \
  sh -c 'mysqldump --single-transaction --quick \
    -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases' \
  | gzip > "$BACKUP_DIR/mysql-$TIMESTAMP.sql.gz"

# Backup volumen estatico
docker run --rm \
  -v uploads_volume:/source:ro \
  -v "$BACKUP_DIR":/backup \
  alpine \
  tar czf "/backup/uploads-$TIMESTAMP.tar.gz" -C /source .

# Limpia backups antiguos
find "$BACKUP_DIR" -name "*.gz" -mtime +$RETENTION_DAYS -delete

sudo chmod 700 /usr/local/bin/docker-backup.sh
sudo crontab -e

0 3 * * * /usr/local/bin/docker-backup.sh >> /var/log/docker-backup.log 2>&1

Verificación y restauración

Un backup que nunca fue probado no es backup — es un archivo. Valida la restauración periódicamente, idealmente en VPS de staging.

Para restaurar un volumen de datos estáticos:

# Crea volumen vacio
docker volume create uploads_restored

# Restaura contenido
docker run --rm \
  -v uploads_restored:/target \
  -v /var/backups/docker-volumes:/backup \
  alpine \
  sh -c 'cd /target && tar xzf /backup/uploads-20260529-030000.tar.gz'

Para restaurar MySQL:

gunzip -c /var/backups/docker-volumes/mysql-20260529-030000.sql.gz \
  | docker exec -i mysql_container mysql -u root -p"$MYSQL_ROOT_PASSWORD"

Después de la restauración, valida integridad — para MySQL, ejecuta CHECK TABLE en las tablas principales; para datos de aplicación, levanta un contenedor apuntando al volumen restaurado y verifica funcionalidad.

Resolución de problemas

”Cannot create container: volume in use”

Aparece cuando intentas eliminar o renombrar un volumen montado en un contenedor activo. Detén el contenedor primero con docker stop antes de manipular el volumen. El backup con :ro monta el volumen en paralelo sin conflicto.

Tarball corrupto durante la restauración

Síntoma: tar: Unexpected EOF in archive. La causa común es disco lleno durante el backup — el archivo fue truncado. Siempre monitorea el espacio libre (df -h) antes de correr backup, y agrega verificación en el script: tar tzf archivo.tar.gz > /dev/null && echo OK.

Backup lento incluso en SSD

Verifica si está siendo escrito en el mismo disco del volumen original — la competición de I/O reduce el throughput a la mitad. Backup hacia disco separado (block storage adicional o red) acelera significativamente. En VPS Hostini, puedes agregar volumen block separado desde el panel para dedicarlo a la zona de backup.

Próximos pasos

Con el backup configurado y validado, considera los próximos niveles de madurez: implementar backup incremental con restic o borg para volúmenes grandes (reduce tiempo y espacio en ~80%), configurar alertas en el script para notificar fallos vía webhook o email, y separar backups por ventana (diario 14 días, semanal 8 semanas, mensual 12 meses) para cubrir escenarios diferentes de recuperación.

Si estás llevando esto a producción, una VPS Hostini ya viene con SSD NVMe y opción de volumen block adicional dedicado a backup, lo que elimina la competición de I/O entre datos activos y copia de seguridad. Para workloads críticos, considera también replicación síncrona a otra región — el backup resuelve pérdida de datos, la replicación resuelve indisponibilidad.