mysqldump Backup: Coherencia y Restauración MySQL/MariaDB

Cuando se habla de gestión de bases de datos, el backup no es solo una buena práctica, es un requisito operativo fundamental. Una interrupción del servicio puede costar miles de euros por hora Gartner y, sin un backup fiable, la restauración se convierte en una tarea casi imposible. MySQL y MariaDB, al ser dos de las bases de datos relacionales más difundidas, requieren estrategias de backup robustas y, sobre todo, coherentes. Muchos administradores confían en mysqldump por su simplicidad y versatilidad, pero conocer sus opciones avanzadas es crucial para evitar sorpresas desagradables.

mysqldump es la herramienta de línea de comandos por excelencia para crear backups lógicos de bases de datos MySQL y MariaDB. Genera un conjunto de instrucciones SQL que pueden ejecutarse para recrear la base de datos o las bases de datos originales. Su fuerza reside en la capacidad de exportar tanto la estructura (esquema) como los datos, lo que lo hace ideal para migraciones, recuperaciones ante desastres y pruebas en entornos de desarrollo. Sin embargo, su eficacia depende enteramente de cómo se utilice, en particular para garantizar la coherencia transaccional.

Versiones de referencia: MySQL 8.0 · MariaDB 11.2 · documentación consultada en noviembre de 2026

mysqldump o backup físico: cuándo basta con un dump

La elección entre un backup lógico con mysqldump y un backup físico (como los ofrecidos por Percona XtraBackup o los snapshots a nivel de filesystem) depende del escenario. Los backups físicos suelen ser más rápidos para bases de datos muy grandes y permiten una restauración point-in-time más granular, pero requieren mayor complejidad y espacio. mysqldump es la elección ideal cuando:

• La base de datos no es extremadamente grande (hasta algunas decenas de GB).
• Necesitas un backup portable, fácilmente restaurable en diferentes versiones de MySQL/MariaDB o en otros sistemas operativos.
• Quieres excluir o incluir tablas específicas, o modificar los datos antes de la restauración.
• No puedes permitirte tiempos de bloqueo prolongados para la aplicación.

Para bases de datos más grandes o con requisitos de RTO (Recovery Time Objective) y RPO (Recovery Point Objective) muy estrictos, un enfoque híbrido o el uso de herramientas de backup físico puede ser más apropiado. Sin embargo, para la mayoría de los entornos de pequeñas y medianas dimensiones, mysqldump ofrece un equilibrio excelente entre simplicidad y fiabilidad.

Backup coherente sin bloquear las tablas

El problema principal de un backup no coherente se manifiesta cuando la base de datos está en uso. Si mysqldump lee las tablas mientras se están realizando operaciones de escritura, los datos exportados podrían no reflejar un estado transaccionalmente consistente. Esto es particularmente cierto para los motores de almacenamiento no transaccionales como MyISAM. Para los motores transaccionales como InnoDB (el predeterminado en MySQL y MariaDB), la solución es la opción --single-transaction.

Cuando usas --single-transaction, mysqldump inicia una transacción aislada antes de comenzar la exportación. Esto significa que todos los datos leídos durante el dump reflejarán el estado de la base de datos en el momento del inicio de la transacción, garantizando la coherencia sin bloquear las operaciones de escritura en la base de datos. Es fundamental que todas las tablas involucradas sean de tipo transaccional (InnoDB).

mysqldump --single-transaction --routines --triggers --events appdb | gzip > appdb_$(date +%F).sql.gz

Este comando realiza el dump de la base de datos appdb de forma transaccionalmente coherente. La salida se comprime luego con gzip y se guarda en un archivo cuyo nombre incluye la fecha actual. Este es el comando base que usaré a menudo como ejemplo para los backups de una sola base de datos. Lee también: logrotate Linux: Configurar Rotación de Logs

Atención: --single-transaction no funciona con las tablas MyISAM o con tablas que no soportan las transacciones. Si tu base de datos contiene tablas MyISAM, estas se bloquearán con un LOCK TABLES para garantizar la coherencia, lo que podría causar un breve tiempo de inactividad. Siempre es aconsejable convertir las tablas MyISAM a InnoDB cuando sea posible.

Incluir procedimientos, triggers y eventos

Un backup no está completo si incluye solo los datos y la estructura de las tablas. Muchas bases de datos modernas hacen un amplio uso de objetos como stored procedures, funciones, triggers y eventos programados. Si estos no se incluyen en el backup, la base de datos restaurada podría no funcionar correctamente o perder funcionalidades críticas.

mysqldump ofrece opciones específicas para incluir estos objetos:

• --routines: incluye los stored procedures y las funciones definidas por el usuario.
• --triggers: incluye los triggers asociados a las tablas.
• --events: incluye los eventos programados.

Es una buena práctica incluir siempre estas opciones cuando se ejecuta un backup completo de una base de datos de aplicación, a menos que se esté absolutamente seguro de que la base de datos no los utiliza o que estos objetos pueden recrearse por separado. Sin ellos, la restauración podría dejarte con una aplicación que no encuentra la lógica de negocio necesaria para operar.

Backup de todas las bases de datos

En un entorno de servidor que aloja múltiples bases de datos, podría ser necesario ejecutar un backup completo de todas las bases de datos presentes. mysqldump lo permite con la opción --all-databases.

mysqldump --single-transaction --all-databases > all.sql

Este comando exportará todas las bases de datos (excluyendo information_schema, performance_schema y otras bases de datos de sistema que por defecto no se incluyen). También aquí, el uso de --single-transaction es crucial para mantener la coherencia entre las diferentes bases de datos, siempre que todas utilicen motores transaccionales. La salida puede dirigirse a un archivo comprimido como se vio antes.

En el caso de MariaDB, la herramienta equivalente es mariadb-dump. Las opciones son casi idénticas a mysqldump.

mariadb-dump --single-transaction appdb > appdb.sql

Esto asegura que, independientemente de la distribución (MySQL o MariaDB), el proceso de backup sea estandarizado y fiable. Lee también: Oracle Data Pump: Export e Import con expdp e impdp

Comprimir y rotar los backups

Los archivos de backup pueden volverse muy grandes, especialmente para bases de datos con muchos datos. La compresión es esencial para ahorrar espacio en disco y reducir los tiempos de transferencia. gzip es la herramienta más común para este propósito y puede integrarse fácilmente con mysqldump mediante una pipe.

mysqldump --single-transaction appdb | gzip > /var/backups/mysql/appdb_$(date +%F).sql.gz

La rotación de los backups es igualmente importante. Conservar demasiados backups antiguos consume espacio inútilmente, mientras que conservar muy pocos reduce las opciones de restauración. Un enfoque común es mantener 7 backups diarios, 4 semanales y 12 mensuales. Esto puede gestionarse con logrotate o con scripts personalizados que eliminan los archivos más antiguos. Lee también: Docker Espacio Disco: Prune, Logs y Imágenes

Una salida típica de un backup comprimido:

-rw-r----- 1 mysql mysql 1.2G Nov  6 10:30 appdb_2026-11-06.sql.gz

Restaurar una base de datos

El verdadero valor de un backup se mide en el momento de la restauración. Restaurar una base de datos desde un archivo mysqldump comprimido es un proceso sencillo pero que requiere atención.

gunzip < appdb_2026-10-15.sql.gz | mysql appdb

Este comando descomprime el archivo de backup y lo pasa directamente al cliente mysql, que lo ejecuta en la base de datos appdb. Es fundamental que la base de datos appdb ya exista, o que el archivo de dump contenga las instrucciones CREATE DATABASE. Si estás restaurando un backup de --all-databases, no especifiques un nombre de base de datos al cliente mysql.

Antes de una restauración crítica, asegúrate de:

1. Tener suficiente espacio en disco: La base de datos restaurada puede ocupar mucho más espacio que el archivo comprimido.
2. Verificar la versión de MySQL/MariaDB: Problemas de compatibilidad entre versiones diferentes pueden surgir durante la restauración.
3. Deshabilitar temporalmente los triggers o las foreign keys: En algunos casos, para acelerar la restauración o evitar errores de integridad, podría ser útil deshabilitar temporalmente los controles de integridad referencial o los triggers, volviéndolos a habilitar al final.

Credenciales sin contraseña en claro (option file)

Insertar las contraseñas directamente en los scripts de backup es una práctica riesgosa para la seguridad. Una alternativa mucho más segura es utilizar un option file, típicamente ~/.my.cnf.

Crea o modifica el archivo ~/.my.cnf (en el directorio home del usuario que ejecuta el backup) con el siguiente contenido:

[client]
user=backup
password=la_tua_password_segura

Posteriormente, establece los permisos correctos para el archivo, de modo que solo el propietario pueda leerlo y escribirlo:

chmod 600 ~/.my.cnf

Ahora, mysqldump y mysql leerán automáticamente las credenciales de este archivo, sin que tengas que especificarlas en la línea de comandos. Esto mejora notablemente la seguridad, reduciendo el riesgo de que las contraseñas se expongan en logs, en la historia de la shell o en procesos visibles.

Automatizar con cron y verificar el resultado

La automatización es la clave para un proceso de backup fiable. cron es la herramienta estándar en Linux para programar la ejecución de scripts a intervalos regulares. Un ejemplo de entrada crontab para un backup diario podría ser:

0 2 * * * /usr/local/bin/backup_mysql.sh > /var/log/backup_mysql.log 2>&1

El script backup_mysql.sh contendrá todos los comandos mysqldump y de rotación. Es crucial que este script:

• Gestione los errores: Controle el código de salida de mysqldump y gzip.
• Genere logs detallados: Registre el resultado del backup, el tamaño del archivo, posibles errores.
• Envíe notificaciones: En caso de fallo, envíe un correo electrónico o una alerta a un sistema de monitorización. Lee también: Zabbix Agent 2: Instalación, Configuración y Plugins

Un paso demasiado a menudo descuidado es la verificación del backup. No basta con que el archivo exista. Es una buena práctica:

1. Controlar el tamaño del archivo: Un archivo de backup inusualmente pequeño podría indicar un error.
2. Ejecutar un gunzip -t: Verifica la integridad del archivo .gz sin descomprimirlo completamente.
3. Restaurar una muestra: Periódicamente, restaurar un backup en un entorno de prueba para asegurarse de que es válido y que el proceso de restauración funciona. Esta es la única verdadera prueba de un backup eficaz.

Errores comunes y resolución de problemas

Error o mensaje exacto	Causa	Solución

Preguntas frecuentes

¿Puedo usar mysqldump para un backup en caliente con MyISAM?

No, --single-transaction funciona solo con motores transaccionales como InnoDB. Para las tablas MyISAM, mysqldump usará LOCK TABLES, que bloqueará las escrituras y algunas lecturas. Para un backup en caliente de MyISAM sin bloqueos, deberías considerar soluciones de backup físico o snapshots a nivel de almacenamiento, pero siempre es aconsejable migrar a InnoDB para una fiabilidad transaccional superior.

¿Cuánto tiempo tarda mysqldump en una base de datos de 100GB?

El tiempo depende de muchos factores: velocidad del disco, I/O del servidor, complejidad del esquema, número de filas y carga en la base de datos. Una base de datos de 100GB puede requerir desde pocos minutos hasta varias horas. La compresión con gzip ralentizará la exportación pero reducirá el tiempo de transferencia y el espacio final. Siempre prueba los tiempos en tu entorno específico.

¿Es posible hacer un backup incremental con mysqldump?

mysqldump crea backups lógicos completos. No soporta directamente backups incrementales o diferenciales. Para obtener backups incrementales, debes combinar mysqldump con el binlog de MySQL/MariaDB, o utilizar herramientas como Percona XtraBackup que están diseñadas para este propósito. El binlog permite la restauración point-in-time después de un backup completo.

¿Cómo puedo excluir tablas específicas del backup?

Puedes usar la opción --ignore-table varias veces para excluir tablas específicas. Por ejemplo: mysqldump appdb --ignore-table=appdb.log_table --ignore-table=appdb.temp_data. Esto es útil para excluir tablas de log o de caché que no son esenciales para la restauración y que solo ocuparían espacio en el backup.

¿Debo crear un usuario MySQL dedicado para los backups?

Sí, es una práctica de seguridad fundamental. Crea un usuario MySQL con el mínimo conjunto de privilegios necesarios para ejecutar el backup (principalmente SELECT, LOCK TABLES para MyISAM, SHOW VIEW, TRIGGER, PROCESS, EVENT y RELOAD para los binlog). Evita usar el usuario root para los backups automatizados, para limitar la superficie de ataque en caso de compromiso de las credenciales.

Conclusiones con puntos clave operativos

La gestión de los backups de MySQL y MariaDB no debe ser una operación compleja o arriesgada. Adoptando las prácticas correctas con mysqldump, puedes garantizar la coherencia y la fiabilidad de tus datos. Los puntos clave a llevar a casa son:

• Prioridad a la coherencia: Usa siempre --single-transaction para los motores transaccionales.
• Backup completo: No olvides --routines, --triggers y --events.
• Seguridad de las credenciales: Utiliza el option file ~/.my.cnf con permisos 600.
• Automatización y verificación: Programa los backups con cron, comprímelos y, sobre todo, prueba periódicamente el proceso de restauración.

Un backup no probado es un backup inexistente. Dedica el tiempo necesario a implementar y validar tu estrategia de backup: es el seguro más importante para la continuidad operativa de tus servicios.

Fuentes

• MySQL 8.0 Reference Manual – mysqldump
• MariaDB Knowledge Base – mariadb-dump
• Gartner: Data Loss Incidents

Actualizado: noviembre de 2026