MySQL物理备份恢复实战：XtraBackup全量增量备份与克隆从库

mysqldump是逻辑备份，恢复时要重放SQL，100GB库的恢复动辄数小时起；XtraBackup是物理备份工具，直接拷贝InnoDB数据文件，备份与恢复速度均以文件复制为上限，配合增量备份能力，是中大型MySQL生产备份体系的标准选择。以下覆盖全量、增量、恢复、从库搭建的完整流程，以及生产备份策略的设计要点。

XtraBackup工作原理：为什么备份期间不锁表

XtraBackup在备份期间后台持续重放redo log，维持备份文件内部的一致性视图：数据文件拷贝过程中数据库持续写入，redo log的增量部分被持续追加到备份集，直到拷贝完成时刻的LSN为止。因此备份期间业务完全不受影响（仅在启动与收尾阶段短暂持有FTWRL锁刷新表元数据）。恢复时的prepare阶段做crash recovery：应用备份期间积累的redo log，让数据文件回到完全一致的状态。

与mysqldump的本质差异：逻辑备份是SQL文本，恢复等于重放全部写入，随数据量线性放大；物理备份是文件级拷贝，恢复接近”复制+回放少量日志”，100GB与1TB的恢复时长差异远小于逻辑备份。RTO（恢复时长）敏感的业务，物理备份几乎是必选项。

全量备份操作与prepare阶段处理

# 全量备份到指定目录
xtrabackup --backup \
  --target-dir=/data/backups/full \
  --user=bkpuser --password=*** \
  --socket=/tmp/mysql.sock

# prepare（恢复前必做，应用redo log）
xtrabackup --prepare --target-dir=/data/backups/full

# 查看备份元信息
cat /data/backups/full/xtrabackup_checkpoints
# backup_type = full-backuped
# from_lsn = 0
# to_lsn = 45378291023
# last_lsn = 45378291032

两个易错点：备份目录不能是已存在且非空的目录；prepare完成后原备份目录保持只读状态，二次prepare前不要复制使用，多个增量合并时prepare的执行顺序有严格次序。

增量备份链与合并恢复流程

# 基于全量做第1次增量
xtrabackup --backup \
  --target-dir=/data/backups/inc1 \
  --incremental-basedir=/data/backups/full \
  --user=bkpuser --password=***

# 基于第1次增量做第2次增量
xtrabackup --backup \
  --target-dir=/data/backups/inc2 \
  --incremental-basedir=/data/backups/inc1 \
  --user=bkpuser --password=***

# 恢复：先prepare全量（--apply-log-only），依次合并增量
xtrabackup --prepare --apply-log-only \
  --target-dir=/data/backups/full
xtrabackup --prepare --apply-log-only \
  --target-dir=/data/backups/full \
  --incremental-dir=/data/backups/inc1
xtrabackup --prepare \
  --target-dir=/data/backups/full \
  --incremental-dir=/data/backups/inc2

# 拷贝回数据目录
xtrabackup --copy-back --target-dir=/data/backups/full
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld

–apply-log-only只前滚不回滚，用于中间环节保持增量链可继续合并；最后一个增量prepare时不加该参数，完成完整恢复。恢复期间目标库必须停机，数据目录必须为空目录。全量+增量的经典节奏是”周日全量、工作日每日增量”，保留至少2个全量周期，恢复演练每季度执行一次——没有演练过的备份等于没有备份。

克隆从库：备份流式传输到备机搭建主从

XtraBackup支持流式输出，备份与传输一体化完成：

# 在主库执行，流式压缩传输到备机
xtrabackup --backup \
  --stream=xbstream \
  --user=bkpuser --password=*** \
  | gzip - | ssh backup@192.168.1.20 \
    "gunzip - | xbstream -x -C /data/mysql_new"

# 备机上prepare并启动为新从库
xtrabackup --prepare --target-dir=/data/mysql_new
chown -R mysql:mysql /data/mysql_new
mysqld --datadir=/data/mysql_new &

# 从备份元信息中取得binlog位点
cat /data/mysql_new/xtrabackup_bin_info
# mysql-bin.000342 98234012

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.1.10',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='***',
  SOURCE_LOG_FILE='mysql-bin.000342',
  SOURCE_LOG_POS=98234012;
START REPLICA;
SHOW REPLICA STATUS\G

流式传输避免了备机落盘中间文件，1TB库的克隆从库搭建在万兆内网下约2-3小时完成，而逻辑备份重建往往超过24小时。GTID模式下更简单：备份集的gtid_executed记录在xtrabackup_info中，CHANGE REPLICATION SOURCE时直接指定SOURCE_AUTO_POSITION=1，不需要手工找位点。

备份策略设计与监控指标保障

生产备份体系的五个设计要点：

• 频率：全量每周1次错峰执行，增量每日1次；核心库叠加binlog实时归档，实现任意时间点恢复（PITR）。
• 存储：本地保留最近1个全量周期用于快速恢复，异地（对象存储或异地机房）保留≥30天，备份加密后传输。
• 校验：每日备份完成后自动对备份集做prepare验证（–prepare到独立目录），prepare失败立即告警，防止”备份成功但恢复失败”。
• 监控：备份耗时趋势、备份集大小环比、增量LSN跨度三个指标接入告警；大小环比骤降往往意味着备份不完整。
• 权限：备份账号只授予RELOAD、PROCESS、LOCK TABLES、REPLICATION CLIENT最小权限，密码独立管理。

binlog归档与物理备份组合实现秒级PITR：恢复时先恢复最近全量+增量，再重放binlog到指定时间点（mysqlbinlog –start-position与–stop-datetime控制区间）。数据误删场景的RTO由此从”按天”压到”按小时”，这是备份体系的最终价值锚点。

XtraBackup的开源许可在8.0版本后随Percona Server分发，社区版对MySQL 8.0的备份需要使用xtrabackup 8.x并注意与MySQL小版本的兼容矩阵，升级MySQL前先确认备份工具支持版本，避免备份静默失败——这类事故在实际生产中的出现频率远高于备份工具本身的缺陷。