Backups de MySQL que de fato restauram — XtraBackup, binlogs e o drill trimestral

Um backup que você nunca restaurou é esperança, não backup. Toda base MySQL gerenciada que operamos tem Percona XtraBackup tirando backups físicos em cronograma, binlogs arquivados continuamente para point-in-time recovery, e um drill de restauração trimestral que prova que ambos ainda funcionam.

O modo de falha comum: backups têm sucesso por um ano, depois um gap de binlog por causa de um blip de rede há três meses significa que o PITR só consegue recuperar até antes do gap. Quando alguém percebe, o gap é velho demais para importar.

O comando base do XtraBackup

xtrabackup --backup \
  --target-dir=/var/backups/mysql/full-$(date +%F) \
  --user=backup --password=... \
  --parallel=4 --compress --compress-threads=4 \
  --no-version-check
 
# Depois 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 é o que torna o backup de fato utilizável — e é o passo que traz à tona corrupção, redo log faltando ou mismatch de versão antes de você precisar restaurar.

O artigo completo cobre:

• Por que backups físicos batem o mysqldump para qualquer DB não trivial
• Arquivamento contínuo de binlog — o padrão rsync/inotify que rodamos
• Point-in-time recovery para uma coordenada de binlog específica
• O drill de restauração trimestral (provisionar um host limpo, restaurar, smoke test)
• Verificação de backup — xtrabackup --prepare e as catástrofes que ele pega cedo
• Criptografar backups em repouso, rotação de chaves e armazenamento offsite

Rodamos isso para cada cliente MySQL gerenciado.