Backup físico full + incremental e restore com XtraBackup

Comando

# Full backup
xtrabackup --backup --host=127.0.0.1 --user=bkp --password='Bkp#2024' --target-dir=/backup/full --parallel=4
# Incremental (based on the previous backup)
xtrabackup --backup --host=127.0.0.1 --user=bkp --password='Bkp#2024' --target-dir=/backup/inc1 --incremental-basedir=/backup/full

# Prepare: full and intermediate incrementals with --apply-log-only, final step without it
xtrabackup --prepare --apply-log-only --target-dir=/backup/full
xtrabackup --prepare --apply-log-only --target-dir=/backup/full --incremental-dir=/backup/inc1
xtrabackup --prepare --target-dir=/backup/full

# Restore: mysqld stopped and datadir empty
systemctl stop mysqld
xtrabackup --copy-back --target-dir=/backup/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld
cat /backup/full/xtrabackup_binlog_info

O que faz

Faz um backup físico a quente copiando os arquivos InnoDB e o redo log com o servidor em execução; um backup incremental contém apenas as páginas alteradas desde o backup anterior. A etapa de prepare aplica o redo e torna o backup consistente.

Quando usar

Para bancos grandes que precisam de restores rápidos (muitas vezes mais rápidos que o lógico), para alimentar réplicas e para estratégias de full diário + incremental de hora em hora.

Atenção

A versão do XtraBackup deve corresponder à série de versão do servidor (servidor 8.0 → XtraBackup 8.0, 8.4 → 8.4); se o servidor usar um formato de redo / data dictionary mais novo que o build do XtraBackup, o backup é recusado. Um backup sem prepare é inconsistente. Esquecer --apply-log-only nas etapas intermediárias inutiliza os incrementais posteriores. O datadir deve estar vazio para o restore; --move-back economiza disco, mas consome o backup. Usuário de backup: BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT e SELECT em performance_schema.log_status, keyring_component_status, replication_group_members.