Cómo hacer copias de seguridad de volúmenes de Docker en 2026: guía para autoalojados

Para respaldar un volumen de Docker, lo montas en un contenedor temporal y lo archivas; no puedes limitarte a copiar la carpeta que está bajo /var/lib/docker/volumes y confiar en ella. El comando de una sola línea que funciona con la mayoría de los volúmenes es un contenedor Alpine desechable que empaqueta los datos con tar en un archivo que tú controlas. La verdad más incómoda, y la parte que la mayoría de los tutoriales se saltan, es que un volumen de base de datos en vivo copiado de esta forma suele quedar sutilmente corrupto, y una copia de seguridad que nunca has restaurado no es una copia de seguridad. Esta guía cubre los comandos exactos, cómo manejar bien las bases de datos, cómo automatizar y enviar copias fuera del servidor, y cómo demostrar que la copia de seguridad realmente funciona.

¿Cómo se respalda un volumen de Docker?

El método estándar consiste en ejecutar un contenedor efímero que monte tu volumen con nombre en modo solo lectura y escriba un tarball comprimido en un directorio del host montado mediante bind. Un único comando se encarga de todo:

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

Esto arranca Alpine, monta el volumen mydata como /source (solo lectura) y escribe un .tar.gz con marca de tiempo en ./backups del host. La guía de copias de seguridad de OneUptime usa este mismo patrón de tar en solo lectura, lo más parecido a un enfoque canónico. Funciona porque la propia documentación de Docker señala que los volúmenes son más fáciles de respaldar que los bind mounts: los datos residen en una única ubicación gestionada. Para una caché de aplicación sin estado o un almacén de archivos, con esto basta. Para cualquier cosa que contenga una base de datos, no.

Por qué copiar un volumen en vivo no es suficiente

Las copias de seguridad a nivel de sistema de archivos dan por hecho que los archivos en disco están en un estado coherente en el momento en que los lees. Una base de datos en ejecución rara vez lo está. Postgres, MySQL y MongoDB almacenan las escrituras en memoria y las vuelcan a disco según su propio calendario, así que empaquetar con tar un directorio de datos en vivo puede capturar una transacción escrita a medias o un índice que apunta a filas que aún no han llegado. La restauración falla entonces o, peor aún, carga datos corruptos de forma silenciosa. La regla práctica de quienes lo hacen a diario es que los dumps específicos de cada base de datos son transaccionalmente coherentes, a diferencia de las copias a nivel de sistema de archivos. Tienes dos opciones seguras: detener el contenedor antes del tar (aceptable en un laboratorio casero, mala idea en cualquier cosa que necesite disponibilidad) o usar la propia herramienta de dump de la base de datos mientras sigue en marcha. La segunda es casi siempre la respuesta correcta.

Respalda las bases de datos con dumps, no con tar

Para una base de datos en contenedor, haz un dump lógico con la herramienta nativa del motor y respalda el archivo del dump en lugar del volumen en bruto. Esto produce una instantánea coherente incluso mientras la base de datos atiende tráfico en vivo. Para Postgres, pg_dump con --single-transaction da una exportación coherente en un punto temporal sin bloqueos prolongados, según la documentación oficial de PostgreSQL:

docker exec -t my-postgres \
  pg_dump -U postgres --single-transaction mydb \
  | gzip > backups/mydb-$(date +%Y%m%d).sql.gz

MySQL y MariaDB usan mysqldump --single-transaction (coherente para tablas InnoDB); MongoDB usa mongodump. El orden importa cuando lo automatizas: primero haz el dump de la base de datos y luego ejecuta la copia del volumen o la copia externa sobre el directorio que ahora contiene el dump reciente. Si autoalojas un stack de backend completo, la misma lógica se aplica al Postgres que corre por debajo: la guía de producción para autoalojar Supabase se apoya en el mismo patrón de «dump primero, almacenar después» en lugar de copiar los archivos de datos.

Automatízalo: herramientas frente a restic

Ejecutar estos comandos a mano una vez es fácil; acordarse de ejecutarlos cada noche es donde fallan los autoalojados. Dos enfoques maduros automatizan todo el ciclo. Un contenedor específico como offen/docker-volume-backup gestiona la programación, la rotación y la subida en una sola imagen: respalda volúmenes en S3, WebDAV, Azure Blob, Dropbox, Google Drive o destinos SSH, con cifrado GPG opcional y rotación automática de copias antiguas, y puede detener un contenedor durante la ejecución para garantizar la integridad cuando se lo indicas con una etiqueta. La alternativa es restic, que ofrece copias de seguridad cifradas, deduplicadas e incrementales hacia casi cualquier backend; un patrón habitual mantiene --keep-daily 7 --keep-weekly 4 --keep-monthly 6 y, gracias a la deduplicación, cada ejecución nocturna solo guarda lo que ha cambiado.

Método	¿En línea (sin detener)?	Destinos externos	Cifrado	Ideal para
tar de una línea	No (detener para BD)	Copia manual	Ninguno (añadir GPG)	Instantáneas rápidas y puntuales
offen/docker-volume-backup	Detención opcional	S3, WebDAV, Azure, Dropbox, GDrive, SSH	GPG	Copias de volúmenes de configurar y olvidar
restic	Sí (con dumps)	S3, B2, SFTP, REST, local	Integrado	Historial deduplicado y versionado
Dump de BD (pg_dump)	Sí	Canalizar a cualquiera de los anteriores	Vía destino	Bases de datos, siempre

Para la mayoría de los stacks autoalojados, la combinación ganadora es un pg_dump (o mysqldump) nocturno que alimenta una ejecución de restic que envía una copia cifrada y deduplicada fuera del servidor.

Aplica la regla 3-2-1 y llévala fuera del servidor

Una copia de seguridad en el mismo VPS que los datos te protege de un despliegue defectuoso, no de que el servidor muera, de un impago de la factura o de un ransomware. La veterana regla 3-2-1 lo soluciona: conserva 3 copias de tus datos, en 2 medios distintos, con 1 fuera del servidor. En la práctica, eso significa el volumen en vivo, un directorio de copia local y una copia en almacenamiento de objetos remoto. El almacenamiento externo es lo bastante barato como para que el coste no sea excusa. A julio de 2026, la Storage Box BX11 de Hetzner cuesta €3.20/mes por 1 TB por SSH/SFTP —un destino natural para restic o rsync—, mientras que Backblaze B2 sale por unos $7 por TB al mes con una API compatible con S3 que tanto restic como offen/docker-volume-backup hablan de forma nativa. Cualquiera de los dos convierte la copia externa en unos pocos euros al mes. Si ya estás vigilando tu factura tras las subidas de precios de los VPS en 2026, el almacenamiento de objetos para copias es el último sitio donde recortar.

Restáurala, y prueba la restauración

La restauración es la única parte de una copia de seguridad que de verdad importa, y es el paso que casi todo el mundo se salta. Para restaurar una copia hecha con tar, detén el contenedor y luego extrae el archivo de vuelta al volumen (vacío):

docker run --rm \
  -v mydata:/target \
  -v $(pwd)/backups:/backup:ro \
  alpine tar xzf /backup/mydata-20260717-120000.tar.gz -C /target

Para un dump de base de datos, cárgalo en un contenedor nuevo y comprueba el esquema y el número de filas antes de fiarte de él. Programa un simulacro de restauración real —mensual es razonable— en un contenedor desechable, levanta la aplicación contra los datos restaurados y confirma que funciona. Una copia de seguridad que nunca has restaurado es una esperanza, no un plan de recuperación. Integra esto en tu flujo de trabajo igual que reforzarías un servidor nuevo en la primera hora segura de la configuración de un VPS.

Preguntas frecuentes

¿Puedo respaldar un volumen de Docker sin detener el contenedor?

Sí, con un matiz. Para almacenes de archivos y cachés, montar el volumen en solo lectura y empaquetarlo con tar mientras el contenedor está en marcha es correcto. Para bases de datos, no empaquetes con tar el volumen en vivo: usa en su lugar la herramienta de dump del motor (pg_dump, mysqldump, mongodump), que produce una exportación coherente sin detener el servicio.

¿Dónde se almacenan realmente los volúmenes de Docker?

En Linux, los volúmenes con nombre residen en /var/lib/docker/volumes/<name>/_data. Técnicamente puedes copiar ese directorio, pero respaldar a través de un contenedor (o un dump en el caso de las bases de datos) es más seguro y portable entre hosts, y por eso la documentación de Docker recomienda el enfoque de montar el volumen.

¿Cuál es la mejor herramienta para automatizar las copias de volúmenes de Docker?

Para copias de volúmenes sin intervención, con programación, rotación y subida a la nube incorporadas, offen/docker-volume-backup es la opción de un solo contenedor más popular. Para un historial deduplicado, cifrado y versionado a través de muchos backends, restic es la opción más fuerte. Muchas configuraciones combinan un dump nocturno de la base de datos con un envío de restic fuera del servidor.

¿Con qué frecuencia debería respaldar?

Ajusta la frecuencia a la cantidad de datos que puedes permitirte perder. Cada noche es el valor por defecto habitual para las aplicaciones autoalojadas; una base de datos muy activa puede justificar dumps cada hora. Sea cual sea la cadencia, conserva varias generaciones (por ejemplo, 7 diarias, 4 semanales, 6 mensuales) para que una corrupción que detectes tarde siga siendo recuperable.

Sources

• OneUptime — Cómo respaldar y restaurar volúmenes de Docker: los comandos de copia y restauración con tar en solo lectura, y el punto de que los dumps de bases de datos son transaccionalmente coherentes donde no lo son las copias a nivel de sistema de archivos.
• Docker Docs — Volumes: la recomendación oficial de que los volúmenes son más fáciles de respaldar y migrar que los bind mounts, y dónde se almacenan los datos de los volúmenes.
• Documentación de PostgreSQL — pg_dump: el comportamiento de dump coherente de --single-transaction para bases de datos en vivo.
• offen/docker-volume-backup (GitHub): backends de almacenamiento compatibles, cifrado GPG, programación, detención del contenedor durante la copia y rotación.
• restic: copias de seguridad cifradas, deduplicadas e incrementales en múltiples backends de almacenamiento.
• Hetzner Storage Box y precios de Backblaze B2: costes de almacenamiento externo citados (julio de 2026).