Introducción a backup y restauración

Los datos son el activo más valioso de cualquier sistema. Un fallo de hardware, un error humano que ejecuta un DELETE sin WHERE, un ataque de ransomware o simplemente una actualización que sale mal pueden destruir horas, días o años de información en cuestión de segundos. Tener una estrategia de backup sólida no es opcional, es la diferencia entre un incidente menor y una catástrofe irrecuperable.

En este artículo exploramos los conceptos fundamentales que necesitas entender antes de implementar tu estrategia de respaldo en MySQL.

Tipos de backup

Los backups se clasifican según tres dimensiones principales: el método utilizado, la cantidad de datos incluidos y el estado del servidor durante la copia.

Backup lógico vs backup físico

Un backup lógico exporta los datos como sentencias SQL que pueden recrear la base de datos. La herramienta mysqldump genera este tipo de respaldo, produciendo un archivo de texto con sentencias CREATE TABLE, INSERT y otras instrucciones DDL y DML. La ventaja principal es la portabilidad: puedes restaurar un backup lógico en cualquier versión de MySQL o incluso en otro motor de base de datos con modificaciones menores. La desventaja es que tanto la creación como la restauración son más lentas porque MySQL debe interpretar y ejecutar cada sentencia SQL.

Un backup físico copia directamente los archivos de datos del sistema de archivos. Es significativamente más rápido tanto para crear como para restaurar, especialmente en bases de datos grandes. Sin embargo, los archivos físicos dependen de la versión de MySQL, el sistema operativo, la arquitectura del hardware y la configuración del motor de almacenamiento. Herramientas como MySQL Enterprise Backup o Percona XtraBackup realizan backups físicos.

-- Ejemplo conceptual: backup lógico genera sentencias SQL
-- El archivo resultante contiene:
CREATE TABLE productos (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nombre VARCHAR(200) NOT NULL,
    precio DECIMAL(10,2)
) ENGINE=InnoDB;
 
INSERT INTO productos VALUES (1, 'iPhone 15 Pro', 1299.99);
INSERT INTO productos VALUES (2, 'Samsung Galaxy S24', 899.99);
-- ... miles de sentencias INSERT

Backup completo, incremental y diferencial

Un backup completo contiene todos los datos de la base de datos en un momento dado. Es el tipo más simple y el más fácil de restaurar, pero también el que más espacio ocupa y el que más tiempo tarda en crearse.

Un backup incremental contiene solo los cambios realizados desde el último backup, ya sea completo o incremental. Ocupa menos espacio y se crea más rápido, pero la restauración requiere aplicar la cadena completa: primero el backup completo y luego cada incremental en orden.

Un backup diferencial contiene todos los cambios desde el último backup completo. Es un punto medio entre ambos: ocupa más que un incremental pero se restaura más rápido porque solo necesitas el completo y el último diferencial.

Backup en caliente, en tibio y en frío

Un backup en caliente (hot backup) se realiza mientras el servidor está funcionando normalmente sin interrumpir las operaciones. Es esencial para sistemas que requieren disponibilidad 24/7. Las tablas InnoDB soportan backups en caliente gracias a su mecanismo MVCC.

Un backup en tibio (warm backup) se realiza con el servidor corriendo pero con restricciones. Por ejemplo, las tablas pueden bloquearse para lectura durante el proceso, lo que permite consultas SELECT pero bloquea las escrituras.

Un backup en frío (cold backup) requiere detener el servidor MySQL por completo. Garantiza la consistencia total pero implica tiempo de inactividad. Consiste simplemente en copiar el directorio de datos de MySQL.

Conceptos de RTO y RPO

Dos métricas fundamentales definen los requisitos de tu estrategia de backup.

El RPO (Recovery Point Objective) es la cantidad máxima de datos que puedes permitirte perder, medida en tiempo. Un RPO de 1 hora significa que en el peor escenario perderás como máximo una hora de datos. Un RPO de cero significa que no puedes perder ni una sola transacción, lo que requiere replicación síncrona.

El RTO (Recovery Time Objective) es el tiempo máximo aceptable para restaurar el servicio después de un fallo. Un RTO de 4 horas significa que el sistema debe estar operativo de nuevo en menos de 4 horas tras el incidente.

Estas métricas determinan directamente tu estrategia:

Herramientas de MySQL para backup

MySQL ofrece varias herramientas para crear y restaurar respaldos, cada una adecuada para diferentes escenarios.

mysqldump es la herramienta más utilizada para backups lógicos. Viene incluida con MySQL y funciona en todas las versiones. Genera archivos SQL que pueden comprimirse y transportarse fácilmente. Es ideal para bases de datos de tamaño pequeño a mediano (hasta decenas de GB).

mysqlpump es una versión mejorada de mysqldump con soporte para paralelismo. Puede crear backups más rápido al procesar varias tablas simultáneamente, aunque tiene algunas limitaciones con la consistencia entre tablas.

mysql (el cliente de línea de comandos) es la herramienta estándar para restaurar backups lógicos. Lee el archivo SQL y ejecuta cada sentencia contra el servidor.

mysqlbinlog permite leer y aplicar binary logs, lo que es esencial para recuperación point-in-time. Complementa a mysqldump para escenarios donde necesitas recuperar datos hasta un momento exacto.

MySQL Enterprise Backup es una herramienta comercial que realiza backups físicos en caliente de tablas InnoDB. Es la opción más rápida para bases de datos grandes pero requiere una licencia de MySQL Enterprise.

Percona XtraBackup es la alternativa open source a MySQL Enterprise Backup. Realiza backups físicos en caliente y soporta backups incrementales y comprimidos. Es ampliamente utilizada en entornos de producción.

Diseñar una estrategia de backup

Una estrategia efectiva combina diferentes tipos de backup según tus requisitos de RPO y RTO. Una configuración común para un sistema de producción mediano sería:

# Backup completo semanal (domingo 2 AM)
0 2 * * 0 mysqldump --single-transaction --routines --triggers --all-databases | gzip > /backups/completo_$(date +\%Y\%m\%d).sql.gz
 
# Backup diario de binary logs (cada día a las 2 AM)
0 2 * * 1-6 mysqlbinlog --read-from-remote-server --raw --stop-never-slave-server-id=1 ...
 
# Verificar el backup mensualmente
0 4 1 * * /scripts/verificar-backup.sh

La estrategia 3-2-1 es un estándar de la industria: mantén al menos 3 copias de tus datos, en 2 tipos de medio diferentes, con 1 copia fuera del sitio. En la práctica, esto podría significar el servidor de producción, un servidor de backup local y una copia en almacenamiento en la nube.

Verificar los backups

Un backup que nunca se ha probado no es un backup. Es sorprendentemente común descubrir que los respaldos están corruptos, incompletos o que la restauración tarda mucho más de lo esperado justo cuando se necesitan.

Programa restauraciones periódicas en un servidor de prueba para verificar que los backups son válidos y que el proceso de restauración funciona dentro de tu RTO:

# Restaurar en servidor de prueba y verificar
mysql -h servidor-prueba -u admin -p < /backups/completo_20260215.sql
 
# Verificar conteos de filas
mysql -h servidor-prueba -u admin -p -e "
SELECT 'productos' AS tabla, COUNT(*) AS filas FROM tienda_mysql.productos
UNION ALL
SELECT 'pedidos', COUNT(*) FROM tienda_mysql.pedidos
UNION ALL
SELECT 'clientes', COUNT(*) FROM tienda_mysql.clientes;
"

Retención y rotación

Los backups acumulados ocupan espacio. Define una política de retención clara: por ejemplo, conservar los backups diarios de la última semana, los semanales del último mes y los mensuales del último año. Automatiza la eliminación de backups antiguos:

# Eliminar backups con más de 30 días
find /backups -name "*.sql.gz" -mtime +30 -delete

Seguridad de los backups

Los archivos de backup contienen todos tus datos, incluidos los sensibles. Protege los backups con cifrado y controles de acceso estrictos:

# Backup cifrado con GPG
mysqldump --single-transaction --all-databases | gzip | gpg --encrypt --recipient admin@empresa.com > /backups/backup_cifrado.sql.gz.gpg
 
# Permisos restrictivos en el directorio de backups
chmod 700 /backups

Documentar el procedimiento

Documenta paso a paso el procedimiento de restauración completo, incluyendo tiempos estimados, servidores involucrados, credenciales necesarias y contactos de emergencia. Cuando ocurre un desastre, el estrés hace que la gente olvide pasos simples. Un procedimiento documentado y probado marca la diferencia.

Con estos conceptos fundamentales claros, en los siguientes artículos entraremos en detalle con cada herramienta y escenario. Empezaremos con mysqldump, la herramienta de backup más utilizada en MySQL.