做 MySQL 运维的人应该都经历过这种时刻某天凌晨业务突然报错你心里一紧第一反应是“数据库最近一次备份是哪天”结果一查mysqldump 出来的文件是十二个小时前的数据丢失窗口大到能装下一整夜的交易流水。我早期维护一套订单库的时候就是靠 mysqldump 硬扛数据量到几百 GB 之后每次全量备份都要跑大半夜恢复一次更要等上几个小时。后来换成 xtrabackup 做物理备份才算把这块心病解决了。这篇就是我实践 xtrabackup 备份 MySQL 数据库的完整记录包括了备份原理、全量与增量实操、恢复演练以及我在真实环境里踩过的坑。适合正在做数据库备份方案选型、或者想让备份更可靠的同学参考。1. 为什么选 xtrabackup备份方案的选型逻辑1.1 传统备份方式的痛点先说清楚我为什么放弃 mysqldump。它在数据量小的时候确实方便一条命令导出 SQL 文本看一眼就能确认备份内容。但数据量一旦上去它的两个致命问题就暴露了备份耗时长、恢复更加耗时。mysqldump 是逻辑备份本质上是把数据一行行读出来、写成一堆 INSERT 语句。几百 GB 的库光生成文件就要几个小时恢复的时候要逐条执行 SQL索引、约束、触发器一个不少地重建速度比备份还慢。更要命的是在备份过程中如果业务还在写入导出来的数据很可能是不一致的——这个表导到一半另一个表已经被更新了。那时候我为了追求一致性只能挑业务低谷期去备份设置了 --single-transaction 开启一个长事务来获取快照。可 InnoDB 的 MVCC 版本链会累积大量未清理的 undo log有时备份还没跑完磁盘空间就先报警了。这种方案在百 GB 级别勉强能用到 TB 级别就是灾难。1.2 xtrabackup 的核心优势xtrabackup 是 Percona 团队开发的开源备份工具走的是物理备份路线。它直接拷贝 InnoDB 的数据文件.ibd、ibdata1 等底层用 redo log 保证一致性不依赖 SQL 层的逐行导出所以备份速度远快于 mysqldump恢复速度也更快——不用执行任何 SQL直接把文件拷回去就行。它的设计里有几个非常贴合生产环境的特点。一是热备能力备份过程中不阻塞业务读写这在 7x24 小时的系统里几乎是必需项。二是支持增量备份每次只备份自上次备份以来发生变化的页面把备份窗口压缩到几分钟。三是自动记录 binlog 坐标恢复时可以精准定位到某个时间点配合 binlog 做时间点恢复数据丢失窗口可以压到秒级。四是支持压缩加密流式备份可以边备份边压缩直接写到远程存储节省本地磁盘空间。1.3 适用场景和边界根据我实践下来xtrabackup 最适合的场景是数据量超过 50 GB 的 MySQL 实例、要求备份不中断业务的在线系统、需要做定期恢复演练的合规环境。它几乎就是为 InnoDB 存储引擎设计的MyISAM 表也能备份但在备份期间会短暂锁表如果你的库以 MyISAM 为主优势就要打折扣了。这里也要说实话xtrabackup 的学习成本比 mysqldump 高不少。命令参数多备份流程分两步backup 和 prepare恢复之前还要理清目录结构。不过一旦把这套流程跑顺它带来的运维效率提升是显而易见的。后面我会详细拆解每一步是怎么工作的把原理讲透这样参数记不牢也能自己推理出来。2. 核心原理xtrabackup 到底做了什么2.1 物理备份与逻辑备份的区别理解 xtrabackup 的核心首先要区分物理备份和逻辑备份。mysqldump 是逻辑备份它读的是数据的内容导出的是 SQL 语句xtrabackup 是物理备份它读的是数据在磁盘上的形态直接复制底层文件。拿搬家来类比逻辑备份是把家具一件件拆下来、打包、运走到了新家再重新组装物理备份则是把整个房子里的东西原封不动连包装一起搬走。物理备份天然有几个优势不用逐行读取表数据拷贝文件是顺序 IO速度更快恢复时不需要重建索引文件拷回 datadir 就能用启动时间大大缩短整个备份集在对齐位置拷贝数据文件配合 redo log 就能保证一致性不需要像 mysqldump 那样开长事务。但是物理备份也有硬性要求备份盘必须有足够的空间存放整个数据目录的拷贝文件格式依赖 MySQL 版本所以备份文件和数据库版本必须匹配。2.2 redo log 追赶机制xtrabackup 备份 InnoDB 数据时有一个关键技术点叫 redo log 追赶redo log apply。它的大致过程是先启动一个后台线程持续拷贝 InnoDB 的 redo log然后开始逐个拷贝数据文件。数据文件是随机读写的拷贝过程需要时间而这段时间里业务还在持续写入redo log 不断产生新内容。等到数据文件拷贝完xtrabackup 会用拷贝下来的 redo log 去模拟一次数据库崩溃恢复crash recovery把备份时间点之前所有已提交的事务重放到数据文件中同时回滚未提交的事务。这就是 prepare 阶段做的事情。所以为什么 xtrabackup 备份之后不能直接把文件丢给数据库用因为数据文件拷贝的时刻不一致有些页面在备份开始时和结束时状态不同必须经过 prepare 把 redo log 应用进去才能得到一个完整一致的“时间点快照”。2.3 备份集的结构解读执行完一次备份你会得到一个目录里面包含的是一整套 MySQL 数据目录的副本。除了熟悉的 .ibd 文件有几个特殊文件需要认识。xtrabackup_checkpoints 文件记录了这次备份的 LSNLog Sequence Number区间比如备份开始时的 to_lsn 和结束时的 last_lsn增量备份就是靠它来判断该从哪里开始拷贝。xtrabackup_logfile 文件保存着拷贝下来的 redo log。xtrabackup_binlog_info 文件记录了备份时刻的 binlog 文件名和 position这个信息在基于 binlog 做时间点恢复时是关键的起点坐标。理解了这几个文件后面操作就容易了。全量备份的 prepare 是把日志应用到数据文件增量备份的 prepare 则是把增量目录里的变更合并到全量目录。名称和含义是这样的对应关系你在终端里看到那些参数就不会懵。3. 完整实操全量备份与恢复3.1 环境准备和安装我的实践环境是一台 CentOS 7.9 服务器MySQL 版本是 5.7.38xtrabackup 使用的版本是 2.4.14。版本匹配很重要xtrabackup 2.4 系列对应 MySQL 5.78.0 系列的 MySQL 需要 xtrabackup 8.0 系列用错版本会直接报错。如果是 MySQL 8.0还要注意它增加了新的 redo log 格式老版本工具读不了。安装我推荐用官方仓库直接装wget https://downloads.percona.com/downloads/percona-release/percona-release-1.0-27/percona-release-1.0-27.el7.noarch.rpm rpm -ivh percona-release-1.0-27.el7.noarch.rpm yum install percona-xtrabackup-24 -y装完验证一下命令xtrabackup --version另外还需要创建备份用的 MySQL 账号生产环境绝对不要用 root 来跑备份。我给备份账号的最小权限是CREATE USER bkuserlocalhost IDENTIFIED BY StrongPass_2024; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT, SHOW DATABASES ON *.* TO bkuserlocalhost; GRANT BACKUP_ADMIN ON *.* TO bkuserlocalhost; FLUSH PRIVILEGES;RELOAD 和 LOCK TABLES 权限用来执行 FLUSH TABLES WITH READ LOCKPROCESS 权限用来查看线程和执行 SHOW ENGINE INNODB STATUSREPLICATION CLIENT 用来读取 binlog 坐标。如果你用的是 MySQL 5.7 或更早版本没有 BACKUP_ADMIN 权限那就不加最后那行。3.2 全量备份命令我第一次执行的备份命令是这个xtrabackup --backup \ --target-dir/backup/full_$(date %Y%m%d_%H%M%S) \ --userbkuser \ --passwordStrongPass_2024 \ --hostlocalhost \ --parallel4 \ --compress分解一下每个参数的含义。--backup 指定进入备份模式--target-dir 指定备份输出目录我习惯带时间戳方便后续保留多份备份--user 和 --password 是备份账号信息--host 指定连接地址--parallel4 表示用 4 个线程并行拷贝数据文件对多核服务器有明显的加速作用--compress 会在备份时实时压缩数据文件我用 lz4 算法默认压缩比和速度比较均衡。执行完看到日志末尾显示completed OK备份就成功了。审计一下备份目录内容ls -lh /backup/full_20241201_030000/3.3 备份参数说明这里补充几个我后来经常调整的参数方便你按实际环境选择。--compress 可以和 --compress-threadsN 配合用多线程压缩我在 32 核服务器上设置过 --compress-threads8压缩环节不再是瓶颈。--streamxbstream 适合把备份流式输出到管道直接传给远程服务器或对象存储免去本地落盘xtrabackup --backup --streamxbstream \ --target-dir/backup/stream_target \ --userbkuser \ --passwordStrongPass_2024 \ | ssh backupserver cat /backup/full_$(date %Y%m%d).xbstream注意这里即使用了 --stream--target-dir 仍要指定一个临时目录xtrabackup 会把检查点等元信息写进去。如果是大库流式备份能省下不少本地磁盘但依赖网络稳定。备份过程中为了拿到一致性快照xtrabackup 需要执行 FLUSH TABLES WITH READ LOCK简称 FTWRL拿到全局读锁后再拷贝 redo log 起始位置。如果业务写入非常频繁这个锁可能一直等不到可以通过 --ftwrl-timeout30 控制等待超时避免备份进程无限阻塞导致业务卡死。默认值好像是 0 表示无限等待在生产环境一定要设置。3.4 恢复流程备份练得再好恢复没有演练过都等于零。全量恢复的思路是prepare 让备份集达到一致性状态copy-back 把文件拷回数据目录。先模拟一次故障把 MySQL 停掉systemctl stop mysqld然后做 preparextrabackup --prepare --target-dir/backup/full_20241201_030000prepare 的时候xtrabackup 会把之前拷贝的 redo log 应用到数据文件整个目录会变成可用的状态。注意 prepare 是随机读写也吃磁盘 IO我一般给它设置 --use-memory2G 指定可用内存会快一些。接下来把数据复制回去。这里有两种方式--copy-back 会保留原备份目录适合备份还要继续留存的情况--move-back 会把文件移过去省磁盘但备份目录就废了。我建议生产环境用 --copy-back方便保留现场xtrabackup --copy-back --target-dir/backup/full_20241201_030000复制完成后最关键的一步是检查文件属主。xtrabackup 通常以 root 身份运行拷回去的文件 owner 是 root而 mysqld 进程用 mysql 用户运行属主不对会导致启动失败。我每次都会强制改一遍chown -R mysql:mysql /var/lib/mysql然后启动 MySQLsystemctl start mysqld启动之后别急着宣布恢复完成先跑一条查询验证数据SELECT COUNT(*) FROM orders_table; SHOW MASTER STATUS;SHOW MASTER STATUS 看的是当前 binlog 坐标它应该等于备份时的 xtrabackup_binlog_info 里的值代表我们成功恢复到了备份时间点。如果后续还要追 binlog 做时间点恢复可以从备份目录里的 xtrabackup_binlog_info 文件读取起点。4. 增量备份实践4.1 增量备份的原理增量备份是 xtrabackup 最让我省心的功能。它不像逻辑备份那样需要对比全量数据而是依赖 InnoDB 页面级的 LSNLog Sequence Number机制。每个数据页面上都记录了一个 LSN表示这个页面最近一次被修改时的日志序号。xtrabackup 做增量备份时会扫描所有数据页找出 LSN 大于上次全量/增量备份起点的页面只拷贝这些有变更的页面。所以增量备份的大小取决于上次备份之后修改了多少数据而不是总数据量。这里有一个容易踩的坑MySQL 8.0 的 innodb_redo_log_capacity 和 redo log 架构调整后xtrabackup 8.0 对增量备份的处理更依赖 redo log 的连续性。如果你用 8.0一定要保证 redo log 文件设置足够大否则增量备份可能因为日志覆盖而失败。5.7 时代只要 innodb_log_file_size 不小于备份间隔产生的日志量一般不会有问题。4.2 增量备份实操我设计了一个每周的备份计划周日做全量备份周一至周六每天做增量备份。先做一次全量作为基础xtrabackup --backup --target-dir/backup/full_20241201 \ --userbkuser --passwordStrongPass_2024 --parallel4周一的增量备份用 --incremental-basedir 指定基于哪个目录xtrabackup --backup --target-dir/backup/inc_20241202 \ --incremental-basedir/backup/full_20241201 \ --userbkuser --passwordStrongPass_2024 --parallel4周二的增量备份--incremental-basedir 指向周一的增量目录xtrabackup --backup --target-dir/backup/inc_20241203 \ --incremental-basedir/backup/inc_20241202 \ --userbkuser --passwordStrongPass_2024 --parallel4增量备份执行完观察目录里的 xtrabackup_checkpoints会看到类似于 from_lsnxxx、to_lsnyyy 的信息。from_lsn 表示这次备份从哪个点开始to_lsn 表示结束点。恢复时把增量一层层叠到全量上就能把数据推进到最近一次增量备份的时刻。4.3 增量合并技巧增量备份的恢复和全量略有不同prepare 阶段要做两遍。第一遍先 prepare 全量基础目录注意要加上 --apply-log-only 参数表示只做日志应用、不做回滚xtrabackup --prepare --apply-log-only --target-dir/backup/full_20241201然后把第一份增量合并进去xtrabackup --prepare --apply-log-only \ --target-dir/backup/full_20241201 \ --incremental-dir/backup/inc_20241202之后每一份增量都重复这个动作。合并完所有增量最后再执行一次不带 --apply-log-only 的 prepare完成最终回滚阶段xtrabackup --prepare --target-dir/backup/full_20241201这里我强调一下每一次增量合并之间的路径关系容易搞混。很多人以为 prepare 时每次 --incremental-dir 都要指向同一个全量目录其实增量目录是指向“当前合并到哪个备份集”的必须按时间顺序一层层叠。我见过有人在同一天里把多份增量同时传给同一个 prepare 命令结果检查点错乱恢复出来数据不一致。增量合并是个顺序操作没有并行一说。5. 常见问题与排查实录5.1 备份失败排查备份失败集中在几种原因我把日志关键词和解决办法整理成了速查表错误特征常见原因处理方式Cant connect to local MySQL server连接配置错误或 MySQL 未启动检查 --host、socket 路径是否有误确认 mysqld 在运行Failed to flush and lock tablesFTWRL 等待超时设置 --ftwrl-timeout错峰备份减少长事务Disk full备份盘空间不足扩容或改用流式压缩备份及时清理过期备份This version of Percona XtraBackup is not compatible工具版本和 MySQL 版本不匹配确认 xtrabackup 大版本与 MySQL 主版本一致InnoDB log file is too smallredo log 太小增量备份基础信息被覆盖调大 innodb_log_file_size 或减少备份间隔备份失败最危险的情况是“半成功半失败”日志停在中间但目录已经创建了。所以脚本里一定要检查最终退出码和日志里的completed OK字符串不要只看目录是否存在。5.2 恢复失败排查恢复阶段我遇到过几个相当隐蔽的问题。一是 prepare 报Applying redo log... failed多半是备份期间 MySQL 还在启动阶段就执行了备份操作或者数据文件损坏。这时不要轻易重新尝试 prepare检查一下 MySQL 日志里有没有硬件相关报错确认磁盘没有坏道。二是 copy-back 之后 MySQL 无法启动日志里提示[ERROR] InnoDB: ... Permission denied这就是我前面说的属主问题。即使你用了 chown 也可能漏掉一些子目录最稳妥的方式是恢复完对整个 datadir 执行一遍chown -R mysql:mysql。三是启动成功但数据偏旧。这种情况常见于恢复了增量备份但 prepare 阶段把 --apply-log-only 条数弄错或者只恢复了全量没恢复增量。恢复完成后用备份时的 xtrabackup_binlog_info 里的 binlog 坐标做校验如果当前坐标不一致就要回头检查合并步骤。5.3 性能调优备份过程对生产环境的压力不容小觑。我在实践里通过几个维度把影响控制在可接受范围内。一是限制 IO 和 CPUxtrabackup 没有内置的 IO 限速参数但可以配合ionice -c2 -n7降低备份进程的磁盘优先级用nice -n 10降低 CPU 优先级让业务 IO 优先。比如ionice -c2 -n7 nice -n 10 xtrabackup --backup \ --target-dir/backup/full_$(date %Y%m%d) \ --userbkuser --passwordStrongPass_2024 --parallel4二是监控锁等待备份期间每隔几分钟执行一次SHOW PROCESSLIST;观察有没有大量线程卡在Waiting for table flush状态如果有说明 FTWRL 没拿到太久就要考虑中断备份或调大 --ftwrl-timeout。三是避开业务高峰即使 xtrabackup 是热备大量 IO 还是会影响磁盘性能把备份窗口安排在凌晨低峰期会从容得多。6. 把备份做成自动化体系6.1 备份策略设计备份不是跑一条命令而是要形成一套可持续运转的体系。我建议的策略是“每周全量 每日增量 保留窗口 定期演练”。全量备份留存 4 周增量保留最近 14 天这样既能满足“恢复到任意最近时间点”的需求也不会让磁盘爆掉。同时binlog 要单独做归档尤其是 binlog 在备份机器上没开启的话时间点恢复的能力就没有了。MySQL 的 binlog 至少要保留最近 14 天并且建议定期把 binlog 也拷到异地存储。6.2 脚本骨架我写了下面这个 shell 脚本用于每天执行备份任务支持全量和增量模式。脚本先检查备份目录再按照参数执行备份并校验结果#!/bin/bash # backup.sh - xtrabackup 全量/增量备份脚本 set -e BK_USERbkuser BK_PASSStrongPass_2024 BK_DIR/backup DATE$(date %Y%m%d) MODE$1 # full | inc BASEDIR$2 # 增量模式的 basedir全量模式为空 mkdir -p $BK_DIR if [ $MODE full ]; then TARGET$BK_DIR/full_$DATE xtrabackup --backup --target-dir$TARGET \ --user$BK_USER --password$BK_PASS --parallel4 --compress elif [ $MODE inc ]; then TARGET$BK_DIR/inc_$DATE xtrabackup --backup --target-dir$TARGET \ --incremental-basedir$BASEDIR \ --user$BK_USER --password$BK_PASS --parallel4 --compress else echo Usage: $0 {full|inc} [basedir] exit 1 fi # 校验备份结果 if [ -f $TARGET/xtrabackup_checkpoints ] \ tail -1 /var/log/xtrabackup.log | grep -q completed OK; then echo backup success: $TARGET else echo backup failed: $TARGET exit 1 fi脚本里最关键的是最后那个校验很多自动化翻车都是因为脚本只管执行、不管结果。建议再把备份时长写入监控如果某天备份耗时异常说明系统有性能问题或数据量增长过快。6.3 监控与告警备份监控这件事我吃过亏才重视起来。有一次备份目录因为磁盘满导致备份失败cron 里的脚本直接报错退出但没人及时注意到直到一周后要做恢复演练才发现备份全断了。从那之后我加了两个约定一是备份日志统一打到固定文件并配置日志采集二是将备份任务的退出码和耗时上报到监控系统超过阈值或失败就告警。有了告警还要有“恢复演练”的意识。我每季度做一次全量恢复演练流程是拿一份全量备份 最近增量在一台隔离环境完整走一遍 prepare、copy-back、启动、校验数据。演练暴露过的问题包括备份文件不完整、prepare 参数写错、chown 漏掉子目录。如果不是提前发现真到生产故障那天备份就是废纸。说实话我在实际维护这套方案时最大的体会是“备份是否可用”比“备份是否成功”更重要而备份是否可用只有靠恢复演练才能验证。建议你接手任何一套生产环境第一件事不是调优备份速度而是做一次恢复演练把备份集的可用性确认下来。这样心里才有底。 
长河君 · 2026/10/20 22:10:13 · 阅读 1.2k MySQL数据库备份方案实践：xtrabackup全量增量备份与恢复
做 MySQL 运维的人应该都经历过这种时刻某天凌晨业务突然报错你心里一紧第一反应是“数据库最近一次备份是哪天”结果一查mysqldump 出来的文件是十二个小时前的数据丢失窗口大到能装下一整夜的交易流水。我早期维护一套订单库的时候就是靠 mysqldump 硬扛数据量到几百 GB 之后每次全量备份都要跑大半夜恢复一次更要等上几个小时。后来换成 xtrabackup 做物理备份才算把这块心病解决了。这篇就是我实践 xtrabackup 备份 MySQL 数据库的完整记录包括了备份原理、全量与增量实操、恢复演练以及我在真实环境里踩过的坑。适合正在做数据库备份方案选型、或者想让备份更可靠的同学参考。1. 为什么选 xtrabackup备份方案的选型逻辑1.1 传统备份方式的痛点先说清楚我为什么放弃 mysqldump。它在数据量小的时候确实方便一条命令导出 SQL 文本看一眼就能确认备份内容。但数据量一旦上去它的两个致命问题就暴露了备份耗时长、恢复更加耗时。mysqldump 是逻辑备份本质上是把数据一行行读出来、写成一堆 INSERT 语句。几百 GB 的库光生成文件就要几个小时恢复的时候要逐条执行 SQL索引、约束、触发器一个不少地重建速度比备份还慢。更要命的是在备份过程中如果业务还在写入导出来的数据很可能是不一致的——这个表导到一半另一个表已经被更新了。那时候我为了追求一致性只能挑业务低谷期去备份设置了 --single-transaction 开启一个长事务来获取快照。可 InnoDB 的 MVCC 版本链会累积大量未清理的 undo log有时备份还没跑完磁盘空间就先报警了。这种方案在百 GB 级别勉强能用到 TB 级别就是灾难。1.2 xtrabackup 的核心优势xtrabackup 是 Percona 团队开发的开源备份工具走的是物理备份路线。它直接拷贝 InnoDB 的数据文件.ibd、ibdata1 等底层用 redo log 保证一致性不依赖 SQL 层的逐行导出所以备份速度远快于 mysqldump恢复速度也更快——不用执行任何 SQL直接把文件拷回去就行。它的设计里有几个非常贴合生产环境的特点。一是热备能力备份过程中不阻塞业务读写这在 7x24 小时的系统里几乎是必需项。二是支持增量备份每次只备份自上次备份以来发生变化的页面把备份窗口压缩到几分钟。三是自动记录 binlog 坐标恢复时可以精准定位到某个时间点配合 binlog 做时间点恢复数据丢失窗口可以压到秒级。四是支持压缩加密流式备份可以边备份边压缩直接写到远程存储节省本地磁盘空间。1.3 适用场景和边界根据我实践下来xtrabackup 最适合的场景是数据量超过 50 GB 的 MySQL 实例、要求备份不中断业务的在线系统、需要做定期恢复演练的合规环境。它几乎就是为 InnoDB 存储引擎设计的MyISAM 表也能备份但在备份期间会短暂锁表如果你的库以 MyISAM 为主优势就要打折扣了。这里也要说实话xtrabackup 的学习成本比 mysqldump 高不少。命令参数多备份流程分两步backup 和 prepare恢复之前还要理清目录结构。不过一旦把这套流程跑顺它带来的运维效率提升是显而易见的。后面我会详细拆解每一步是怎么工作的把原理讲透这样参数记不牢也能自己推理出来。2. 核心原理xtrabackup 到底做了什么2.1 物理备份与逻辑备份的区别理解 xtrabackup 的核心首先要区分物理备份和逻辑备份。mysqldump 是逻辑备份它读的是数据的内容导出的是 SQL 语句xtrabackup 是物理备份它读的是数据在磁盘上的形态直接复制底层文件。拿搬家来类比逻辑备份是把家具一件件拆下来、打包、运走到了新家再重新组装物理备份则是把整个房子里的东西原封不动连包装一起搬走。物理备份天然有几个优势不用逐行读取表数据拷贝文件是顺序 IO速度更快恢复时不需要重建索引文件拷回 datadir 就能用启动时间大大缩短整个备份集在对齐位置拷贝数据文件配合 redo log 就能保证一致性不需要像 mysqldump 那样开长事务。但是物理备份也有硬性要求备份盘必须有足够的空间存放整个数据目录的拷贝文件格式依赖 MySQL 版本所以备份文件和数据库版本必须匹配。2.2 redo log 追赶机制xtrabackup 备份 InnoDB 数据时有一个关键技术点叫 redo log 追赶redo log apply。它的大致过程是先启动一个后台线程持续拷贝 InnoDB 的 redo log然后开始逐个拷贝数据文件。数据文件是随机读写的拷贝过程需要时间而这段时间里业务还在持续写入redo log 不断产生新内容。等到数据文件拷贝完xtrabackup 会用拷贝下来的 redo log 去模拟一次数据库崩溃恢复crash recovery把备份时间点之前所有已提交的事务重放到数据文件中同时回滚未提交的事务。这就是 prepare 阶段做的事情。所以为什么 xtrabackup 备份之后不能直接把文件丢给数据库用因为数据文件拷贝的时刻不一致有些页面在备份开始时和结束时状态不同必须经过 prepare 把 redo log 应用进去才能得到一个完整一致的“时间点快照”。2.3 备份集的结构解读执行完一次备份你会得到一个目录里面包含的是一整套 MySQL 数据目录的副本。除了熟悉的 .ibd 文件有几个特殊文件需要认识。xtrabackup_checkpoints 文件记录了这次备份的 LSNLog Sequence Number区间比如备份开始时的 to_lsn 和结束时的 last_lsn增量备份就是靠它来判断该从哪里开始拷贝。xtrabackup_logfile 文件保存着拷贝下来的 redo log。xtrabackup_binlog_info 文件记录了备份时刻的 binlog 文件名和 position这个信息在基于 binlog 做时间点恢复时是关键的起点坐标。理解了这几个文件后面操作就容易了。全量备份的 prepare 是把日志应用到数据文件增量备份的 prepare 则是把增量目录里的变更合并到全量目录。名称和含义是这样的对应关系你在终端里看到那些参数就不会懵。3. 完整实操全量备份与恢复3.1 环境准备和安装我的实践环境是一台 CentOS 7.9 服务器MySQL 版本是 5.7.38xtrabackup 使用的版本是 2.4.14。版本匹配很重要xtrabackup 2.4 系列对应 MySQL 5.78.0 系列的 MySQL 需要 xtrabackup 8.0 系列用错版本会直接报错。如果是 MySQL 8.0还要注意它增加了新的 redo log 格式老版本工具读不了。安装我推荐用官方仓库直接装wget https://downloads.percona.com/downloads/percona-release/percona-release-1.0-27/percona-release-1.0-27.el7.noarch.rpm rpm -ivh percona-release-1.0-27.el7.noarch.rpm yum install percona-xtrabackup-24 -y装完验证一下命令xtrabackup --version另外还需要创建备份用的 MySQL 账号生产环境绝对不要用 root 来跑备份。我给备份账号的最小权限是CREATE USER bkuserlocalhost IDENTIFIED BY StrongPass_2024; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT, SHOW DATABASES ON *.* TO bkuserlocalhost; GRANT BACKUP_ADMIN ON *.* TO bkuserlocalhost; FLUSH PRIVILEGES;RELOAD 和 LOCK TABLES 权限用来执行 FLUSH TABLES WITH READ LOCKPROCESS 权限用来查看线程和执行 SHOW ENGINE INNODB STATUSREPLICATION CLIENT 用来读取 binlog 坐标。如果你用的是 MySQL 5.7 或更早版本没有 BACKUP_ADMIN 权限那就不加最后那行。3.2 全量备份命令我第一次执行的备份命令是这个xtrabackup --backup \ --target-dir/backup/full_$(date %Y%m%d_%H%M%S) \ --userbkuser \ --passwordStrongPass_2024 \ --hostlocalhost \ --parallel4 \ --compress分解一下每个参数的含义。--backup 指定进入备份模式--target-dir 指定备份输出目录我习惯带时间戳方便后续保留多份备份--user 和 --password 是备份账号信息--host 指定连接地址--parallel4 表示用 4 个线程并行拷贝数据文件对多核服务器有明显的加速作用--compress 会在备份时实时压缩数据文件我用 lz4 算法默认压缩比和速度比较均衡。执行完看到日志末尾显示completed OK备份就成功了。审计一下备份目录内容ls -lh /backup/full_20241201_030000/3.3 备份参数说明这里补充几个我后来经常调整的参数方便你按实际环境选择。--compress 可以和 --compress-threadsN 配合用多线程压缩我在 32 核服务器上设置过 --compress-threads8压缩环节不再是瓶颈。--streamxbstream 适合把备份流式输出到管道直接传给远程服务器或对象存储免去本地落盘xtrabackup --backup --streamxbstream \ --target-dir/backup/stream_target \ --userbkuser \ --passwordStrongPass_2024 \ | ssh backupserver cat /backup/full_$(date %Y%m%d).xbstream注意这里即使用了 --stream--target-dir 仍要指定一个临时目录xtrabackup 会把检查点等元信息写进去。如果是大库流式备份能省下不少本地磁盘但依赖网络稳定。备份过程中为了拿到一致性快照xtrabackup 需要执行 FLUSH TABLES WITH READ LOCK简称 FTWRL拿到全局读锁后再拷贝 redo log 起始位置。如果业务写入非常频繁这个锁可能一直等不到可以通过 --ftwrl-timeout30 控制等待超时避免备份进程无限阻塞导致业务卡死。默认值好像是 0 表示无限等待在生产环境一定要设置。3.4 恢复流程备份练得再好恢复没有演练过都等于零。全量恢复的思路是prepare 让备份集达到一致性状态copy-back 把文件拷回数据目录。先模拟一次故障把 MySQL 停掉systemctl stop mysqld然后做 preparextrabackup --prepare --target-dir/backup/full_20241201_030000prepare 的时候xtrabackup 会把之前拷贝的 redo log 应用到数据文件整个目录会变成可用的状态。注意 prepare 是随机读写也吃磁盘 IO我一般给它设置 --use-memory2G 指定可用内存会快一些。接下来把数据复制回去。这里有两种方式--copy-back 会保留原备份目录适合备份还要继续留存的情况--move-back 会把文件移过去省磁盘但备份目录就废了。我建议生产环境用 --copy-back方便保留现场xtrabackup --copy-back --target-dir/backup/full_20241201_030000复制完成后最关键的一步是检查文件属主。xtrabackup 通常以 root 身份运行拷回去的文件 owner 是 root而 mysqld 进程用 mysql 用户运行属主不对会导致启动失败。我每次都会强制改一遍chown -R mysql:mysql /var/lib/mysql然后启动 MySQLsystemctl start mysqld启动之后别急着宣布恢复完成先跑一条查询验证数据SELECT COUNT(*) FROM orders_table; SHOW MASTER STATUS;SHOW MASTER STATUS 看的是当前 binlog 坐标它应该等于备份时的 xtrabackup_binlog_info 里的值代表我们成功恢复到了备份时间点。如果后续还要追 binlog 做时间点恢复可以从备份目录里的 xtrabackup_binlog_info 文件读取起点。4. 增量备份实践4.1 增量备份的原理增量备份是 xtrabackup 最让我省心的功能。它不像逻辑备份那样需要对比全量数据而是依赖 InnoDB 页面级的 LSNLog Sequence Number机制。每个数据页面上都记录了一个 LSN表示这个页面最近一次被修改时的日志序号。xtrabackup 做增量备份时会扫描所有数据页找出 LSN 大于上次全量/增量备份起点的页面只拷贝这些有变更的页面。所以增量备份的大小取决于上次备份之后修改了多少数据而不是总数据量。这里有一个容易踩的坑MySQL 8.0 的 innodb_redo_log_capacity 和 redo log 架构调整后xtrabackup 8.0 对增量备份的处理更依赖 redo log 的连续性。如果你用 8.0一定要保证 redo log 文件设置足够大否则增量备份可能因为日志覆盖而失败。5.7 时代只要 innodb_log_file_size 不小于备份间隔产生的日志量一般不会有问题。4.2 增量备份实操我设计了一个每周的备份计划周日做全量备份周一至周六每天做增量备份。先做一次全量作为基础xtrabackup --backup --target-dir/backup/full_20241201 \ --userbkuser --passwordStrongPass_2024 --parallel4周一的增量备份用 --incremental-basedir 指定基于哪个目录xtrabackup --backup --target-dir/backup/inc_20241202 \ --incremental-basedir/backup/full_20241201 \ --userbkuser --passwordStrongPass_2024 --parallel4周二的增量备份--incremental-basedir 指向周一的增量目录xtrabackup --backup --target-dir/backup/inc_20241203 \ --incremental-basedir/backup/inc_20241202 \ --userbkuser --passwordStrongPass_2024 --parallel4增量备份执行完观察目录里的 xtrabackup_checkpoints会看到类似于 from_lsnxxx、to_lsnyyy 的信息。from_lsn 表示这次备份从哪个点开始to_lsn 表示结束点。恢复时把增量一层层叠到全量上就能把数据推进到最近一次增量备份的时刻。4.3 增量合并技巧增量备份的恢复和全量略有不同prepare 阶段要做两遍。第一遍先 prepare 全量基础目录注意要加上 --apply-log-only 参数表示只做日志应用、不做回滚xtrabackup --prepare --apply-log-only --target-dir/backup/full_20241201然后把第一份增量合并进去xtrabackup --prepare --apply-log-only \ --target-dir/backup/full_20241201 \ --incremental-dir/backup/inc_20241202之后每一份增量都重复这个动作。合并完所有增量最后再执行一次不带 --apply-log-only 的 prepare完成最终回滚阶段xtrabackup --prepare --target-dir/backup/full_20241201这里我强调一下每一次增量合并之间的路径关系容易搞混。很多人以为 prepare 时每次 --incremental-dir 都要指向同一个全量目录其实增量目录是指向“当前合并到哪个备份集”的必须按时间顺序一层层叠。我见过有人在同一天里把多份增量同时传给同一个 prepare 命令结果检查点错乱恢复出来数据不一致。增量合并是个顺序操作没有并行一说。5. 常见问题与排查实录5.1 备份失败排查备份失败集中在几种原因我把日志关键词和解决办法整理成了速查表错误特征常见原因处理方式Cant connect to local MySQL server连接配置错误或 MySQL 未启动检查 --host、socket 路径是否有误确认 mysqld 在运行Failed to flush and lock tablesFTWRL 等待超时设置 --ftwrl-timeout错峰备份减少长事务Disk full备份盘空间不足扩容或改用流式压缩备份及时清理过期备份This version of Percona XtraBackup is not compatible工具版本和 MySQL 版本不匹配确认 xtrabackup 大版本与 MySQL 主版本一致InnoDB log file is too smallredo log 太小增量备份基础信息被覆盖调大 innodb_log_file_size 或减少备份间隔备份失败最危险的情况是“半成功半失败”日志停在中间但目录已经创建了。所以脚本里一定要检查最终退出码和日志里的completed OK字符串不要只看目录是否存在。5.2 恢复失败排查恢复阶段我遇到过几个相当隐蔽的问题。一是 prepare 报Applying redo log... failed多半是备份期间 MySQL 还在启动阶段就执行了备份操作或者数据文件损坏。这时不要轻易重新尝试 prepare检查一下 MySQL 日志里有没有硬件相关报错确认磁盘没有坏道。二是 copy-back 之后 MySQL 无法启动日志里提示[ERROR] InnoDB: ... Permission denied这就是我前面说的属主问题。即使你用了 chown 也可能漏掉一些子目录最稳妥的方式是恢复完对整个 datadir 执行一遍chown -R mysql:mysql。三是启动成功但数据偏旧。这种情况常见于恢复了增量备份但 prepare 阶段把 --apply-log-only 条数弄错或者只恢复了全量没恢复增量。恢复完成后用备份时的 xtrabackup_binlog_info 里的 binlog 坐标做校验如果当前坐标不一致就要回头检查合并步骤。5.3 性能调优备份过程对生产环境的压力不容小觑。我在实践里通过几个维度把影响控制在可接受范围内。一是限制 IO 和 CPUxtrabackup 没有内置的 IO 限速参数但可以配合ionice -c2 -n7降低备份进程的磁盘优先级用nice -n 10降低 CPU 优先级让业务 IO 优先。比如ionice -c2 -n7 nice -n 10 xtrabackup --backup \ --target-dir/backup/full_$(date %Y%m%d) \ --userbkuser --passwordStrongPass_2024 --parallel4二是监控锁等待备份期间每隔几分钟执行一次SHOW PROCESSLIST;观察有没有大量线程卡在Waiting for table flush状态如果有说明 FTWRL 没拿到太久就要考虑中断备份或调大 --ftwrl-timeout。三是避开业务高峰即使 xtrabackup 是热备大量 IO 还是会影响磁盘性能把备份窗口安排在凌晨低峰期会从容得多。6. 把备份做成自动化体系6.1 备份策略设计备份不是跑一条命令而是要形成一套可持续运转的体系。我建议的策略是“每周全量 每日增量 保留窗口 定期演练”。全量备份留存 4 周增量保留最近 14 天这样既能满足“恢复到任意最近时间点”的需求也不会让磁盘爆掉。同时binlog 要单独做归档尤其是 binlog 在备份机器上没开启的话时间点恢复的能力就没有了。MySQL 的 binlog 至少要保留最近 14 天并且建议定期把 binlog 也拷到异地存储。6.2 脚本骨架我写了下面这个 shell 脚本用于每天执行备份任务支持全量和增量模式。脚本先检查备份目录再按照参数执行备份并校验结果#!/bin/bash # backup.sh - xtrabackup 全量/增量备份脚本 set -e BK_USERbkuser BK_PASSStrongPass_2024 BK_DIR/backup DATE$(date %Y%m%d) MODE$1 # full | inc BASEDIR$2 # 增量模式的 basedir全量模式为空 mkdir -p $BK_DIR if [ $MODE full ]; then TARGET$BK_DIR/full_$DATE xtrabackup --backup --target-dir$TARGET \ --user$BK_USER --password$BK_PASS --parallel4 --compress elif [ $MODE inc ]; then TARGET$BK_DIR/inc_$DATE xtrabackup --backup --target-dir$TARGET \ --incremental-basedir$BASEDIR \ --user$BK_USER --password$BK_PASS --parallel4 --compress else echo Usage: $0 {full|inc} [basedir] exit 1 fi # 校验备份结果 if [ -f $TARGET/xtrabackup_checkpoints ] \ tail -1 /var/log/xtrabackup.log | grep -q completed OK; then echo backup success: $TARGET else echo backup failed: $TARGET exit 1 fi脚本里最关键的是最后那个校验很多自动化翻车都是因为脚本只管执行、不管结果。建议再把备份时长写入监控如果某天备份耗时异常说明系统有性能问题或数据量增长过快。6.3 监控与告警备份监控这件事我吃过亏才重视起来。有一次备份目录因为磁盘满导致备份失败cron 里的脚本直接报错退出但没人及时注意到直到一周后要做恢复演练才发现备份全断了。从那之后我加了两个约定一是备份日志统一打到固定文件并配置日志采集二是将备份任务的退出码和耗时上报到监控系统超过阈值或失败就告警。有了告警还要有“恢复演练”的意识。我每季度做一次全量恢复演练流程是拿一份全量备份 最近增量在一台隔离环境完整走一遍 prepare、copy-back、启动、校验数据。演练暴露过的问题包括备份文件不完整、prepare 参数写错、chown 漏掉子目录。如果不是提前发现真到生产故障那天备份就是废纸。说实话我在实际维护这套方案时最大的体会是“备份是否可用”比“备份是否成功”更重要而备份是否可用只有靠恢复演练才能验证。建议你接手任何一套生产环境第一件事不是调优备份速度而是做一次恢复演练把备份集的可用性确认下来。这样心里才有底。