Cómo respaldar un contenedor Docker de MariaDB (2026)
La forma correcta de respaldar un contenedor MariaDB es un volcado lógico, no una copia de archivos. Ejecuta `mariadb-dump --all-databases --single-transaction --routines --triggers -uroot -p"$MARIADB_ROOT_PASSWORD"` dentro del contenedor y respalda su salida. Copiar /var/lib/mysql mientras MariaDB 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 | MARIADB_ROOT_PASSWORD, MYSQL_ROOT_PASSWORD, MARIADB_DATABASE, MARIADB_USER |
|---|---|
| Puerto por defecto | 3306 |
| Rutas de datos vivas (nunca copiadas en caliente) | /var/lib/mysql |
| Imágenes de ejemplo | mariadb:11, mariadb:10.11, mariadb:10, mariadb |
Respalda MariaDB 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 MariaDB
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 MariaDB. Aún no se respalda nada — solo le indicas a Dockstash dónde vive el proyecto.
Comprueba que MariaDB fue detectado
Abre el proyecto y mira la pestaña Plan. Dockstash lee docker-compose.yml, reconoce la imagen mariadb 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 encontradas (MARIADB_ROOT_PASSWORD, o la antigua MYSQL_ROOT_PASSWORD, más MARIADB_DATABASE y MARIADB_USER). 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 — mariadb-dump con --single-transaction. Verás fluir SQL: CREATE DATABASE, CREATE TABLE e INSERT. Esa salida es lo que se respalda, nunca el directorio vivo /var/lib/mysql.
docker exec <mariadb-container> sh -c 'mariadb-dump --all-databases --single-transaction -uroot -p"$MARIADB_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 MariaDB. 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 mariadb-dump 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
mariadb-dump --all-databases --single-transaction --routines --triggers -uroot -p"$MARIADB_ROOT_PASSWORD"El comando de restauración
mariadb -uroot -p"$MARIADB_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 MariaDB y prueba que funciona
Un respaldo de MariaDB 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 MariaDB de prueba, ejecuta SHOW DATABASES con el cliente mariadb para confirmar que cada esquema volvió y sondea las tablas de tu aplicación.
docker exec <mariadb-container> sh -c 'mariadb -uroot -p"$MARIADB_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 — una copia InnoDB en plena escritura es irrecuperable.
- Las imágenes nuevas traen mariadb-dump; las antiguas usan mysqldump. Dockstash detecta qué binario provee la imagen.
- MariaDB acepta MARIADB_ROOT_PASSWORD o la clave antigua MYSQL_ROOT_PASSWORD: ambas se detectan.
Problemas comunes al respaldar MariaDB
- Síntoma
- El volcado manual falla con « mariadb-dump: command not found ».
- Causa
- Las imágenes MariaDB antiguas (10.4 y anteriores) solo traen el binario mysqldump; mariadb-dump llegó después, con mysqldump como enlace de compatibilidad en las imágenes nuevas.
- Solución
- Usa mysqldump con las mismas opciones en imágenes antiguas — la salida es idéntica. Dockstash detecta qué binario trae la imagen y llama al correcto automáticamente.
- Síntoma
- El volcado falla con « Access denied for user 'root'@'localhost' ».
- Causa
- La clave de contraseña root del compose (MARIADB_ROOT_PASSWORD o la antigua MYSQL_ROOT_PASSWORD) ya no coincide con la contraseña real del volumen — la variable solo la fija en la primera inicialización.
- Solución
- Usa la contraseña con la que se inicializó el volumen, o restablécela dentro del contenedor, y alinea después el env del compose.
- Síntoma
- Restaurar el volcado en un contenedor MySQL falla con errores de sintaxis.
- Causa
- MariaDB y MySQL han divergido — secuencias de MariaDB, ciertas colaciones y opciones de almacenamiento no existen en MySQL; una restauración cruzada puede romper.
- Solución
- Restaura en una imagen MariaDB de la misma versión mayor del volcado. Aborda una migración MariaDB → MySQL solo de forma deliberada, tras limpiar el volcado.
- 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
¿MariaDB se respalda igual que MySQL?
Casi idéntico. Ambos usan --single-transaction para una instantánea InnoDB consistente. La diferencia es el binario cliente: las imágenes MariaDB recientes traen mariadb-dump (mysqldump es un enlace de compatibilidad). Dockstash elige el correcto.
¿Qué clave de contraseña root detecta Dockstash?
Tanto MARIADB_ROOT_PASSWORD como la antigua MYSQL_ROOT_PASSWORD se reconocen, ya que las imágenes MariaDB aceptan una u otra según la versión.
¿Puedo restaurar un volcado MariaDB en MySQL, o al revés?
A menudo, pero no siempre — la deriva de funciones y sintaxis entre ambos rompe casos límite. Restaura en la misma familia de motor del volcado para un resultado fiable.
¿Por qué no simplemente hacer snapshot del volumen?
El volumen /var/lib/mysql se escribe continuamente. Un snapshot en plena escritura es inconsistente. El volcado lógico vía mariadb-dump es la vía restaurable.
¿Con qué frecuencia debo respaldar MariaDB?
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.