Copias de seguridad en MySQL: mysqldump y restauración

Hola, ¿cómo están? Continuando con los temas complementarios del curso de MySQL, hoy veremos las copias de seguridad.

Es la lección menos entretenida del curso y probablemente la más importante. Un sistema sin respaldos es un sistema que funciona hasta el día que deja de funcionar.

¡Empecemos!

Qué puede salir mal

Los respaldos no son solo para cuando se quema el servidor. Los escenarios reales, por frecuencia:

1. Error humano. Un DELETE sin WHERE. Es, con diferencia, la causa número uno.
2. Un despliegue que sale mal y corrompe datos.
3. Fallo de disco.
4. Ataque o secuestro de datos.
5. Necesidad de recuperar cómo estaban las cosas hace un mes, por una consulta legal o contable.

Fíjate en que solo uno de los cinco tiene que ver con hardware.

mysqldump: el respaldo lógico

Genera un archivo .sql con las sentencias necesarias para reconstruir la base.

mysqldump -u root -p clinica > respaldo_clinica.sql

Ese archivo contiene los CREATE TABLE y los INSERT de todo. Es texto plano: puedes abrirlo, leerlo y hasta editarlo.

Opciones que conviene usar

mysqldump -u root -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  clinica > respaldo_clinica.sql

Qué hace cada una, porque importan:

• --single-transaction hace el respaldo dentro de una transacción, así no bloquea las tablas. Imprescindible en producción con InnoDB: sin esto, el sitio queda inaccesible mientras dura el respaldo.
• --routines incluye procedimientos y funciones.
• --triggers incluye los triggers.
• --events incluye eventos programados.

Sin las tres últimas, restauras las tablas pero pierdes toda la lógica almacenada. Es un descubrimiento muy desagradable en el peor momento.

Variantes útiles

# Todas las bases de datos
mysqldump -u root -p --all-databases > respaldo_total.sql

# Solo algunas tablas
mysqldump -u root -p clinica pacientes citas > respaldo_parcial.sql

# Solo la estructura, sin datos
mysqldump -u root -p --no-data clinica > estructura.sql

# Solo los datos, sin estructura
mysqldump -u root -p --no-create-info clinica > datos.sql

# Filtrando filas
mysqldump -u root -p clinica citas --where="fecha >= '2026-01-01'" > citas_2026.sql

La de --no-data es muy práctica para versionar la estructura de la base en Git.

Comprimir

Los respaldos en texto plano comprimen muchísimo:

mysqldump -u root -p --single-transaction clinica | gzip > respaldo_clinica.sql.gz

Un archivo de 2 GB puede quedar en 200 MB. Con respaldos diarios, la diferencia en almacenamiento es enorme.

Restaurar

# Desde un archivo .sql
mysql -u root -p clinica < respaldo_clinica.sql

# Desde uno comprimido
gunzip < respaldo_clinica.sql.gz | mysql -u root -p clinica

La base de datos debe existir antes. Si no:

mysql -u root -p -e "CREATE DATABASE clinica CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p clinica < respaldo_clinica.sql

Restaurar una sola tabla

Si solo necesitas recuperar una tabla de un respaldo completo, extráela con sed:

sed -n '/DROP TABLE.*`citas`/,/UNLOCK TABLES/p' respaldo_clinica.sql > citas.sql
mysql -u root -p clinica < citas.sql

Es incómodo, y por eso conviene hacer respaldos por tabla de las que más importan.

Automatizar los respaldos

Un respaldo manual es un respaldo que algún día no se hace. La automatización no es opcional.

Un script sencillo:

#!/bin/bash
# respaldo.sh

FECHA=$(date +%Y-%m-%d_%H%M)
DESTINO="/var/respaldos/mysql"
BASE="clinica"

mkdir -p "$DESTINO"

mysqldump --defaults-extra-file=/etc/mysql/respaldo.cnf \
  --single-transaction --routines --triggers --events \
  "$BASE" | gzip > "$DESTINO/${BASE}_${FECHA}.sql.gz"

# Conservar solo los últimos 14 días
find "$DESTINO" -name "${BASE}_*.sql.gz" -mtime +14 -delete

Fíjate en --defaults-extra-file: es la forma correcta de no poner la contraseña en el comando, donde quedaría visible para cualquiera que liste los procesos del servidor.

Ese archivo, con permisos restringidos:

[mysqldump]
user=respaldo
password=la-clave

Y se programa con cron:

# Todos los días a las 3 de la mañana
0 3 * * * /ruta/respaldo.sh >> /var/log/respaldo-mysql.log 2>&1

La regla 3-2-1

Es el estándar de la industria y vale la pena seguirlo:

• 3 copias de los datos.
• 2 medios distintos.
• 1 fuera del lugar físico.

Ese último punto es el que más se ignora. Un respaldo guardado en el mismo servidor no es un respaldo: si el servidor falla, se pierde con todo lo demás.

Copia los respaldos a otro sitio: un almacenamiento en la nube, otro servidor, un disco externo. El comando puede ir en el mismo script.

Probar la restauración

Y aquí está el punto que quiero subrayar, porque es el que más disgustos ha causado en la historia de la informática:

Un respaldo que nunca se probó no es un respaldo. Es una suposición.

Los respaldos fallan silenciosamente por muchos motivos: el disco se llenó y el archivo quedó truncado, la contraseña cambió y el script llevaba semanas fallando, faltaban los --routines.

Nadie se entera hasta que hay que restaurar.

Prueba la restauración al menos una vez al trimestre, en un servidor distinto:

mysql -u root -p -e "CREATE DATABASE prueba_restauracion;"
gunzip < respaldo_clinica.sql.gz | mysql -u root -p prueba_restauracion

mysql -u root -p -e "SELECT COUNT(*) FROM prueba_restauracion.citas;"
mysql -u root -p -e "SHOW TRIGGERS FROM prueba_restauracion;"

Comprueba que el número de filas cuadra y que los triggers y procedimientos están.

Respaldo físico

mysqldump es cómodo pero lento con bases muy grandes: restaurar 100 GB puede llevar horas, porque ejecuta millones de INSERT.

Para ese tamaño existen los respaldos físicos, que copian directamente los archivos de datos:

• Percona XtraBackup, gratuito y el estándar para InnoDB.
• MySQL Enterprise Backup, la opción comercial.

Son mucho más rápidos de restaurar y permiten respaldos incrementales.

Regla práctica: hasta unos 20 GB, mysqldump va bien. Por encima, vale la pena mirar XtraBackup.

Respaldo desde las herramientas

En Workbench: Administration → Data Export, eligiendo esquemas y tablas. Y Data Import/Restore para el camino inverso.

En phpMyAdmin: pestaña Exportar. Es lo que usarás en un hosting compartido, donde no tienes acceso a la línea de comandos.

Ambos sirven para respaldos puntuales. Para los automáticos, el script con cron.

Una lista para no olvidar nada

• Respaldo automático diario configurado
• Con --single-transaction, --routines y --triggers
• Comprimido
• Copiado fuera del servidor
• Con rotación, borrando los antiguos
• El script registra si falla, y alguien lee ese registro
• La restauración se probó en los últimos tres meses
• Sabes cuánto tarda restaurar

Ese último punto importa para las expectativas: si restaurar tarda cuatro horas, eso es lo que va a estar caído tu sistema.

Errores comunes

• No tener respaldos. Sigue siendo sorprendentemente frecuente.
• Guardarlos en el mismo servidor.
• No probar nunca la restauración.
• Olvidar --routines y --triggers.
• Respaldar sin --single-transaction y bloquear el sitio.
• La contraseña en el comando, visible en la lista de procesos.
• No revisar si el respaldo automático sigue funcionando.

Para cerrar

Los respaldos son la única red de seguridad real. Todo lo demás —permisos, transacciones, validaciones— reduce la probabilidad de un desastre; el respaldo es lo que te permite recuperarte cuando ocurre igual.

Si te llevas una sola cosa: prueba la restauración. Es lo que separa tener un respaldo de creer que lo tienes.

En la última lección cerramos el curso volviendo al diseño.

Saludos y éxitos.