Cómo respaldar un contenedor Docker de MySQL (2026)
La forma correcta de respaldar un contenedor MySQL es un volcado lógico, no una copia de archivos. Ejecuta `mysqldump --all-databases --single-transaction --routines --triggers -uroot -p"$MYSQL_ROOT_PASSWORD"` dentro del contenedor y respalda su salida. Copiar /var/lib/mysql mientras MySQL escribe produce una instantánea inconsistente; --single-transaction envuelve el volcado en una sola transacción InnoDB, capturando todas las tablas en un punto consistente único sin bloqueo de escritura.
Qué detecta Dockstash
| Claves de entorno detectadas | MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD |
|---|---|
| Puerto por defecto | 3306 |
| Rutas de datos vivas (nunca copiadas en caliente) | /var/lib/mysql |
| Imágenes de ejemplo | mysql:8, mysql:8.0, mysql:5.7, mysql |
Respalda MySQL con Dockstash, paso a paso
Crea tu cuenta de Dockstash y abre el panel
Regístrate gratis en app.dockstash.com/register. El asistente de configuración único te pide tu VPS de almacenamiento (la máquina que guardará los respaldos cifrados) y genera una contraseña de cifrado — guárdala de inmediato en un gestor de contraseñas: se muestra exactamente una vez.
Añade el proyecto Docker que ejecuta MySQL
En la pantalla Projects, Dockstash detecta automáticamente cada carpeta de proyecto Compose del servidor (por defecto bajo /var/www). Elige el proyecto que contiene tu servicio MySQL. Aún no se respalda nada — solo le indicas a Dockstash dónde vive el proyecto.
Comprueba que MySQL fue detectado
Abre el proyecto y mira la pestaña Plan. Dockstash lee docker-compose.yml, reconoce la imagen mysql y añade una capa de base de datos con el comando de volcado correcto — más el nombre del contenedor resuelto y las claves de entorno encontradas (MYSQL_ROOT_PASSWORD, MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD). Puedes activar o desactivar archivos, bases y configuraciones de proxy antes de guardar.
Opcional: comprueba el volcado a mano
Si quieres una prueba antes de automatizar, ejecuta el mismo volcado que ejecutará Dockstash. Deberías ver fluir SQL — sentencias CREATE DATABASE, CREATE TABLE e INSERT. Esa salida es lo que se respalda, nunca el directorio vivo /var/lib/mysql.
docker exec <mysql-container> sh -c 'mysqldump --all-databases --single-transaction -uroot -p"$MYSQL_ROOT_PASSWORD"' | head -n 20Confirma tu destino de almacenamiento
Los respaldos se guardan como instantáneas restic cifradas en tu propio VPS de almacenamiento, vía SSH. Si completaste el asistente, ya está configurado; puedes cambiar host, usuario, puerto o la clave SSH en cualquier momento en Settings → Storage.
Define una programación de respaldo
En la pestaña Schedule elige diario, semanal o una expresión cron personalizada (validada al escribir). Diario a una hora tranquila es el valor por defecto correcto para la mayoría de proyectos MySQL. Añade un prune semanal con tu política de retención.
Ejecuta el primer respaldo ahora
Haz clic en Backup Now en la tarjeta del proyecto. Dockstash ejecuta mysqldump con --single-transaction, --routines y --triggers dentro del contenedor y envía el volcado directamente a restic — sigue la salida en vivo en el panel de logs.
Confirma que la instantánea existe
Al terminar la ejecución, la tarjeta del proyecto muestra la nueva hora del último respaldo, el número de instantáneas y el tamaño del repositorio. Abre la pantalla Snapshots: el punto de restauración aparece en la línea de tiempo — tu prueba de que el respaldo llegó fuera del servidor.
El comando de volcado
mysqldump --all-databases --single-transaction --routines --triggers -uroot -p"$MYSQL_ROOT_PASSWORD"El comando de restauración
mysql -uroot -p"$MYSQL_ROOT_PASSWORD"--single-transaction envuelve el volcado en una sola transacción InnoDB, capturando todas las tablas en un punto consistente único sin bloqueo de escritura.
Restaura un respaldo de MySQL y prueba que funciona
Un respaldo de MySQL solo es real una vez restaurado. Las restauraciones de Dockstash nunca sobrescriben tu base viva por defecto — primero restauras a una ubicación nueva, verificas los datos y promocionas deliberadamente.
Elige un punto de restauración
Abre Snapshots, selecciona el proyecto y recorre la línea de tiempo. Cada fila es un volcado completo a instante único de todas las bases del servidor — esquemas, datos, rutinas y triggers — más los archivos del proyecto de la misma ejecución.
Restaura a una nueva ubicación
Haz clic en Restore y mantén el modo por defecto « Restore to new location ». Escribe el nombre del proyecto para confirmar — una acción deliberada con confirmación tecleada. El volcado y los archivos aterrizan en la ruta de destino que elijas, sin tocar el proyecto vivo.
Verifica los datos restaurados
Carga el volcado en un contenedor MySQL de prueba, ejecuta SHOW DATABASES para confirmar que cada esquema volvió y sondea las tablas de tu aplicación. Recuentos de filas y registros recientes son la prueba más rápida.
docker exec <mysql-container> sh -c 'mysql -uroot -p"$MYSQL_ROOT_PASSWORD" -e "SHOW DATABASES;"'Promociona cuando estés conforme
Cuando los datos restaurados estén validados, apunta tu aplicación a ellos (o repite la restauración en modo « Overwrite existing » — un opt-in explícito). Mejor aún: deja que el simulacro de restauración semanal produzca esta prueba automáticamente, para que una restauración nunca sea tu primer ensayo.
Trampas a evitar
- Nunca ejecutes restic sobre el directorio vivo /var/lib/mysql — tablespaces InnoDB copiados en plena escritura son inconsistentes y fallarán en la recuperación.
- --single-transaction solo da una instantánea consistente para tablas transaccionales (InnoDB); las MyISAM no están cubiertas y necesitan bloqueo.
- Añade --routines y --triggers o los procedimientos almacenados y triggers desaparecen en silencio del volcado.
Problemas comunes al respaldar MySQL
- Síntoma
- El volcado falla con « Access denied for user 'root'@'localhost' ».
- Causa
- El MYSQL_ROOT_PASSWORD del compose ya no coincide con la contraseña real del volumen de datos — la variable solo fija la contraseña en la primera inicialización; cambiarla después en el compose no afecta a un volumen existente.
- Solución
- Usa la contraseña con la que se inicializó el volumen, o restablece la contraseña root dentro del contenedor, y alinea después el env del compose.
- Síntoma
- El volcado termina pero algunas tablas quedan inconsistentes tras restaurar.
- Causa
- Esas tablas son MyISAM. --single-transaction solo garantiza una instantánea consistente para tablas transaccionales InnoDB; las MyISAM se leen fuera de esa garantía.
- Solución
- Comprueba el motor con SHOW TABLE STATUS. Migra las tablas MyISAM a InnoDB (ALTER TABLE ... ENGINE=InnoDB) — el arreglo duradero — o acepta un bloqueo breve con --lock-tables.
- Síntoma
- Restaurar en un contenedor de prueba da « Unknown collation: utf8mb4_0900_ai_ci ».
- Causa
- El volcado viene de MySQL 8.x pero restauras en una imagen 5.7; las colaciones por defecto de 8.0 no existen en servidores antiguos.
- Solución
- Restaura en la misma versión mayor del volcado (por ejemplo mysql:8). Volcar de antiguo a nuevo funciona; lo inverso suele fallar.
- Síntoma
- Una ejecución de respaldo falla con un candado restic obsoleto tras un fallo o reinicio.
- Causa
- Un job anterior murió a mitad de ejecución y dejó el repositorio bloqueado.
- Solución
- No hay nada que hacer a mano: la siguiente ejecución detecta el candado huérfano y ejecuta restic unlock automáticamente antes de continuar. Si las ejecuciones siguen fallando, revisa el panel de logs en vivo para ver el error de fondo.
Hazlo en un clic con Dockstash
Dockstash ejecuta exactamente el volcado de arriba, lo entrega a restic fuera del servidor y prueba la restauración con un simulacro automáticamente — sin script que mantener.
Última actualización: July 2026
Preguntas frecuentes
¿Por qué es importante --single-transaction?
Sin él, mysqldump lee las tablas una a una y una escritura entre tablas produce un volcado inconsistente. --single-transaction lo envuelve todo en una transacción InnoDB: el volcado entero refleja un único instante, sin bloqueo de escritura.
¿El volcado incluye procedimientos almacenados y triggers?
Solo si pasas --routines y --triggers, que Dockstash incluye. Un mysqldump por defecto los omite — causa habitual de una base « restaurada pero rota ».
¿Puedo respaldar MySQL copiando /var/lib/mysql?
No. El tablespace InnoDB y los redo logs se escriben continuamente; una copia de archivos en plena escritura es inconsistente. Dockstash ejecuta mysqldump dentro del contenedor en su lugar.
¿Y si uso tablas MyISAM?
--single-transaction no hace consistente a MyISAM porque ese motor no es transaccional. Si dependes de MyISAM, hace falta un bloqueo breve (--lock-tables) — migrar esas tablas a InnoDB es el arreglo duradero.
¿Con qué frecuencia debo respaldar MySQL?
Diario es el valor por defecto práctico para la mayoría de proyectos; cada hora si perder un día de escrituras es inaceptable. En el plan Free los respaldos son solo manuales; Pro permite programaciones hasta cada hora, Business cualquier cron. Combina la programación con un simulacro de restauración semanal.
¿Dónde viven realmente los respaldos?
En tu propio VPS de almacenamiento, como instantáneas restic cifradas enviadas por SSH. Dockstash nunca guarda tus datos en una nube de terceros — lo apuntas a una máquina que controlas, y el repositorio está cifrado con una contraseña que solo tú tienes.
¿Cómo sé que el respaldo es restaurable sin hacer una restauración manual?
Programa un simulacro de restauración. Dockstash restaura la última instantánea en un espacio de trabajo aislado, compara cada archivo byte a byte con la fuente y verifica el volcado restaurado — luego estampa una insignia de éxito/fallo en el proyecto. Un simulacro semanal significa prueba siempre fresca.