Respaldar contenedores Docker y volúmenes

Qué cubre este artículo sobre copias de seguridad de Docker

• Por qué los respaldos son críticos para contenedores Docker.
• Cómo respaldar volúmenes de forma manual y automática.
• Cómo proteger configuraciones de Compose y variables de entorno.
• Cómo cifrar respaldos y almacenarlos en ubicaciones remotas.
• Restauración y errores comunes.

Introducción: respaldar contenedores Docker y volúmenes

Los contenedores Docker en sí son sin estado. Los datos, configuraciones y cargas de trabajo viven en volúmenes, bind mounts y archivos de Compose. Sin respaldos adecuados, cualquier fallo de hardware, eliminación accidental o actualización defectuosa implica perder todo. Una estrategia de respaldo sólida incluye volúmenes, archivos de Compose, archivos .env, imágenes y copias regulares fuera del sitio.

Este artículo muestra cómo estructurar, automatizar y restaurar respaldos de Docker.

Conceptos clave

• Volume Backup: respaldo de un volumen Docker.
• Bind Mount Backup: respaldo de un directorio montado en el host.
• Compose Backup: respaldo del archivo YAML y variables de entorno.
• Offsite: almacenamiento fuera del servidor propio.
• Snapshot: copia puntual del sistema.
• Restore: recuperación desde un respaldo.
• Retention: período de retención de respaldos.
• rsync: herramienta para respaldos incrementales.

Qué debe respaldarse

Componente	Razón
Docker Volumes	Contienen bases de datos, modelos, configuraciones.
Bind Mounts	Datos persistentes ubicados en el host.
compose.yaml	Define el stack completo.
.env-files	Secretos y configuraciones.
Docker Images	Para recuperación rápida sin descargas adicionales.
Container Settings	Labels, redes, variables de entorno.

Respaldo manual de volúmenes

El método más simple usa un contenedor temporal que monta el volumen:

docker run --rm -v ollama-data:/data -v $(pwd):/backup alpine tar -czf /backup/ollama-data.tar.gz -C /data .

Esto genera un archivo comprimido en el directorio actual.

Restauración manual

docker run --rm -v ollama-data:/data -v $(pwd):/backup alpine tar -xzf /backup/ollama-data.tar.gz -C /data

Importante: el volumen de destino debe existir o crearse previamente.

Respaldar bind mounts

Los bind mounts son directorios normales en el host. Pueden respaldarse con rsync o tar:

rsync -av /opt/ollama-data /backup/ollama-data/

Archivos de Compose y secretos

Mantener un directorio centralizado para todos los proyectos de Compose facilita los respaldos:

rsync -av /opt/docker-compose/ /backup/docker-compose/

Debe contener compose.yaml, archivos .env y configuraciones. Los archivos .env incluyen secretos y requieren cifrado o protección especial.

Respaldos automatizados

Un script Bash para respaldos periódicos:

#!/bin/bash
set -e

BACKUP_DIR="/backup/docker/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$BACKUP_DIR"

# Volumes
for volume in ollama-data pg-data open-webui-data; do
  docker run --rm -v "$volume":/data -v "$BACKUP_DIR":/backup alpine \
    tar -czf "/backup/$volume.tar.gz" -C /data .
done

# Proyectos de Compose
rsync -av /opt/docker-compose/ "$BACKUP_DIR/docker-compose/"

# Logs
echo "Backup creado: $BACKUP_DIR" >> /var/log/docker-backup.log

Cronjob

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

Almacenamiento remoto y cifrado

Los respaldos no deben estar solo localmente. Opciones disponibles:

• Disco duro externo.
• NAS o Synology.
• Cloud storage vía rclone.
• Almacenamientos de objetos compatibles con S3.
• Nodo Tailscale en red remota.

Cifrado con Restic:

restic -r /mnt/backup-repo backup /backup/docker
restic -r /mnt/backup-repo snapshots

Respaldo de bases de datos en operación

Las bases de datos deben respaldarse de forma consistente. Un volcado de base de datos es mejor que solo copiar archivos:

docker exec postgres pg_dumpall -U admin > backup.sql

Para SQLite, se puede copiar el archivo de base de datos mientras no haya transacciones activas.

Restaurar un stack completo

1. Instalar Docker.
2. Transferir respaldos al nuevo host.
3. Restaurar volúmenes.
4. Copiar proyectos de Compose en la ubicación correcta.
5. Ejecutar docker compose up -d.

Estrategias de respaldo

• Regla 3-2-1: tres copias, dos medios, una copia fuera del sitio.
• Incremental: respaldar solo datos modificados.
• Snapshot antes de actualizaciones: hacer respaldo previo a cada actualización importante.
• Test-Restore: verificar regularmente que los respaldos funcionan.
• Monitoring: registrar el éxito del respaldo y alertas en caso de fallo.

Errores comunes

• No respaldar contenedores: los contenedores no tienen estado, los volúmenes son lo crítico.
• Copiar bases de datos en operación: genera respaldos inconsistentes.
• Secretos sin cifrar: los archivos .env contienen contraseñas.
• Retención insuficiente: respaldos antiguos no se eliminan, el almacenamiento se agota.
• No probar restauración: el respaldo funciona pero la restauración no.
• Respaldo solo local: se pierde con fallo de hardware.

Enlaces y recursos útiles

• BotServ.de Docker Volumes
• BotServ.de Docker Compose
• BotServ.de Proxmox Backups y Restore
• BotServ.de Secret-Management

FAQ: respaldos de Docker

¿Debo respaldar contenedores completos? No, respalda volúmenes y archivos de Compose. Los contenedores pueden recrearse.

¿Con qué frecuencia debería respaldar? Diariamente para datos activos, semanalmente para configuraciones estáticas.

¿Son portables los respaldos de volúmenes de Docker? Sí, si se transfieren a un sistema de destino similar.

¿Cómo respaldo secretos? Cifrados o en un gestor de contraseñas.

¿Qué es la regla 3-2-1? Tres copias, dos medios diferentes, una copia fuera del sitio.

Fuentes y lecturas adicionales

• Docker Volumes Backup: https://docs.docker.com/storage/volumes/#back-up-restore-or-migrate-data-volumes
• restic: https://restic.net/
• rsync: https://rsync.samba.org/

Resumen: respaldar contenedores Docker y volúmenes

Los respaldos de configuraciones Docker se centran en volúmenes, bind mounts, archivos de Compose y variables de entorno. Los respaldos manuales con tar y rsync son rápidos, mientras que los automatizados mediante cronjob son necesarios en producción. Lo crítico es hacer volcados consistentes de bases de datos, cifrar secretos, almacenar fuera del sitio y probar restauraciones regularmente. Quien siga la regla 3-2-1 está mucho mejor protegido contra pérdida de datos.