Backups de MySQL que de verdad restauran — XtraBackup, binlogs y el simulacro trimestral

Un backup que nunca has restaurado es esperanza, no un backup. Cada base de datos MySQL gestionada que operamos tiene Percona XtraBackup tomando backups físicos en cronograma, binlogs archivados de forma continua para point-in-time recovery, y un simulacro de restauración trimestral que demuestra que ambos siguen funcionando.

El modo de fallo común: los backups tienen éxito durante un año, luego un gap de binlog por un blip de red de hace tres meses significa que PITR solo puede recuperar a antes del gap. Para cuando alguien lo nota, el gap es demasiado antiguo para importar.

El comando base de XtraBackup

xtrabackup --backup \
  --target-dir=/var/backups/mysql/full-$(date +%F) \
  --user=backup --password=... \
  --parallel=4 --compress --compress-threads=4 \
  --no-version-check
 
# Luego enviar + verificar
aws s3 sync /var/backups/mysql/full-$(date +%F) s3://backups/mysql/full-$(date +%F)/
xtrabackup --prepare --target-dir=/var/backups/mysql/full-$(date +%F)

--prepare es lo que hace el backup realmente utilizable — y es el paso que saca a la luz corrupción, redo log faltante o mismatch de versión antes de que necesites restaurar.

El artículo completo cubre:

• Por qué los backups físicos baten a mysqldump para cualquier BBDD no trivial
• Archivado continuo de binlog — el patrón rsync/inotify que ejecutamos
• Point-in-time recovery a una coordenada binlog específica
• El simulacro de restauración trimestral (aprovisionar un host limpio, restaurar, hacer smoke test)
• Verificación de backup — xtrabackup --prepare y las catástrofes que pilla temprano
• Cifrar backups en reposo, rotación de claves y almacenamiento offsite

Ejecutamos esto para cada cliente MySQL gestionado.