MySQL物理热备实战：Xtrabackup全量+增量备份与恢复演练

数据库备份这件事说简单是真简单很多人写个 mysqldump 的 cron 就觉得自己有备份了说难也真难等到要恢复的那一刻才发现备份文件是坏的、恢复对不上时间点、业务停了几小时。后来我老老实实把 Mysql 物理热备方案搭起来用 Xtrabackup 做全量加增量的组合备份心里才算有底。这篇东西就是把我踩过的坑、验证过的参数、恢复演练的完整过程整理出来给正在选型或者准备上手“Mysql物理热备基于xtrabackup”的同学一个可以直接照着做的参考。1. 为什么我最终选了“物理热备”而不是继续用 mysqldump1.1 逻辑备份和物理备份到底差在哪先别急着敲安装命令把“为什么选它”这件事想清楚后面才不会被各种备份方案带着跑。逻辑备份的代表就是 mysqldump、mydumper。它们的思路是把数据库里的表结构、数据一行一行地导出成 SQL 语句或者其他格式的逻辑数据恢复的时候再一条条执行回去。好处是文件可读、能跨小版本迁移、还能只备份某几张表坏处是“生成备份”和“恢复数据”都要经过 SQL 解析和索引重建数据量一旦上来慢得让人抓狂。我见过一个真实案例某个核心业务库有大概 200G 数据之前一直用 mysqldump 做每日全备备份要跑 3 个多小时恢复更离谱干跑一次要 5 小时以上。后来某次磁盘故障DBA 拿着备份去恢复从夜里两点一直弄到第二天中午业务那边早就炸锅了。这种场景下逻辑备份确实扛不住。物理备份的思路完全不同。它直接拷贝 MySQL 数据目录下的 ibdata1、.ibd 这些原始文件本质上是文件级别复制。恢复的时候把文件放回原位置重新启动实例即可不需要一条条执行 SQL。以同样的 200G 库为例物理备份的备份时间通常能控制在半小时以内恢复也在 1 小时左右差距是数量级的。我整理了一张对比表方便你快速判断场景对比项逻辑备份mysqldump物理备份xtrabackup备份速度慢SQL 导出行级数据快直接复制数据文件恢复速度慢需重放大量 SQL快文件就位即可启动备份产物SQL 或 CSV便于查看二进制数据文件需配套工具读取一致性保证单表/全库锁或事务快照InnoDB 崩溃恢复机制保证跨版本迁移相对宽松与 MySQL/内核版本强相关适合数据量几十 G 以内较好几十 G 到数 T 均可用一句话总结小库随便用 mysqldump 没问题库一旦过了百 G 线、备份窗口又紧物理备份基本是唯一靠谱的方案。1.2 Xtrabackup 热备的原理为什么它能不锁业务这里要解释一下“热备”这个词。热备是指在数据库对外提供读写服务的同时完成备份业务不用停。MySQL 里 InnoDB 引擎天生有事务和崩溃恢复机制它把所有已经提交但还没来得及刷到磁盘的变更记录在 redo log重做日志里。数据库异常重启时会通过 redo log 把这些变更补做回数据文件这就是所谓的崩溃恢复。Xtrabackup 就是吃透了 InnoDB 这套机制。它启动一个后台进程一边扫描复制数据文件一边实时监听并复制这个时间段内新产生的 redo log。复制完成后备份文件里的数据文件有可能处于某个中间时间点但只要把捕获到的 redo log 一起回放一遍数据文件就能达到一个一致性的状态。这个过程就叫 prepare必须在恢复之前执行。这里有个容易误解的点备份过程中业务还在写所以数据文件复制出来时可能“不干净”这是正常的。千万别直接把这种没 prepare 过的目录拿去做恢复否则数据库会认为文件损坏。我第一次用 xtrabackup 时没仔细看文档以为拷完文件就万事大吉恢复后实例起不来日志里全是 redo log 解析错误最后查了一圈才发现是少了 prepare 那一步。至于为什么它能做到“不锁业务”是因为 InnoDB 的 redo log 机制允许数据文件的复制和在线写入并存。Xtrabackup 只在最开始和最后取一个全局的一致性位点期间通过 redo log 记录增量变化所以不会像 mysqldump 那样在备份期间给表加上长时间的全局读锁。对 7x24 在线的业务来说这就是它最核心的价值。1.3 什么场景下物理热备是刚需我接触过的项目里真正把物理热备当刚需的基本逃不出下面几类第一类是核心在线交易库单库数据量超过 100G同时要求 7x24 可用。这种库你不可能每天凌晨停服两三个小时去备份只能用热备。第二类是对 RTO恢复时间目标敏感的业务。比如财务系统、订单系统故障后要求 1 小时内恢复甚至更快。物理备份恢复时直接把文件 copy 回去就行时间主要花在文件拷贝上比逻辑备份快太多。第三类是需求频繁做全量增量组合备份的场景。Xtrabackup 可以通过 LSN日志序列号做增量备份每天一个全量加每小时的增量恢复时能精确到某个时间点附近。mysqldump 做增量虽然也可以靠 binlog但流程会复杂很多。当然物理热备也有它的限制。比如它和 MySQL 版本、发行版内核耦合较深跨大版本恢复经常不兼容备份文件是二进制格式想看某一行数据还得先把实例恢复出来。所以并不是说有了 Xtrabackup 就可以彻底扔掉 mysqldump有些小表迁移、排障导出需求我平时还是会用逻辑备份两者配合才是完整的备份体系。2. Xtrabackup 版本选择与安装避坑2.1 版本对应关系选错直接白干Xtrabackup 是 Percona 公司开源的备份工具目前主流是两个大版本线Percona XtraBackup 2.4 和 Percona XtraBackup 8.0。2.4 主要对应 MySQL 5.6/5.78.0 对应 MySQL 8.0。很多人安装时不看对应关系从官网随便拉一个最新版就装结果连接数据库时报各种 incompatible 错误。我之前有次帮朋友看问题他数据库是 MySQL 5.7直接装了 Percona XtraBackup 8.0一跑备份就报错提示 server version 不匹配折腾了很久才反应过来是版本问题。列表如下建议直接对着找MySQL 5.6 / 5.7 - Percona XtraBackup 2.4MySQL 8.0 - Percona XtraBackup 8.0MySQL 8.4 / 9.x 这类新版本 - 需要看 Percona 官方对应支持矩阵通常建议用最新的 PXB 8.0.x 并关注官方发布说明这里还要注意MySQL 8.0 的不同小版本有时也会遇到兼容性问题。比如 MySQL 8.0.46 这种新小版本Percona 可能需要更新补丁才能完整支持。建议安装前先看 Percona 的官方 release notes确认你用的 PXB 版本能正确备份当前 MySQL 小版本别等备份失败了才去翻。2.2 安装方式和环境准备Xtrabackup 的安装方式有几种我按省事程度排个序官方 apt/yum 仓库安装适用于能联网的机器最推荐。官网下载对应系统的压缩包或 rpm/deb 包适合内网环境。源码编译一般不建议除非你用的系统和官方包完全不匹配。以 CentOS 7 / Rocky Linux 8 为例用 yum 仓库安装的命令大概是yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm percona-release enable-only tools release yum install percona-xtrabackup-80装完看下版本xtrabackup --version如果是 2.4 版本命令文件也叫 xtrabackup另外还会带一个 innobackupex 兼容脚本。8.0 以后官方主推 xtrabackup 命令innobackupex 已经不建议使用了写脚本的时候留意一下不要被旧教程误导。安装时还可能缺 qpress 这个压缩工具它是给 xtrabackup 的 --compress 参数用的如果计划用压缩备份记得一起装上。Debian/Ubuntu 下对应的是 apt install qpressCentOS 下可以从 EPEL 源装。另外不要用 root 系统用户直接跑备份建议单独建一个系统账号比如 backupuser专门负责备份任务避免给数据库一个超级权限账号乱用。后面涉及文件权限时也清爽些。如果 MySQL 跑在 Docker 容器里则需要在容器外面把备份目录挂载进容器再通过 docker exec 进入容器执行 xtrabackupdatadir 路径也要按容器内实际情况修改不能直接照搬本机路径。2.3 核心参数逐项拆解照着选就行Xtrabackup 参数很多实际用的高频参数其实就那么十几个。我按用途把它们拆成几组连接相关--host127.0.0.1 --port3306 --userbackup_user --passwordxxx --socket/tmp/mysql.sock备份时建议用 socket 连走 TCP 也没问题但在高并发库上 socket 连接开销更小响应更快。备份动作相关--backup --target-dir/backup/full/$(date %F)--backup 表示执行备份--target-dir 指定备份输出目录。注意目录不能存在否则 xtrabackup 会拒绝执行避免覆盖同路径老数据。并行和压缩相关--parallel4 --compress --compress-threads2--parallel 控制拷贝多个 .ibd 文件时的并行线程数一般按 CPU 核数的一半设置。如果不想备份文件太占磁盘加 --compress 参数qpress 压缩后体积大概能小 40%-60%但备份和恢复都会多花一些 CPU 时间。增量相关--incremental-basedir/backup/full/20250301 --incremental--incremental-basedir 指向当前增量备份的“基准”也就是上一次全量或增量备份的目录。这个想清楚就理解增量了。从库备份相关--slave-info --safe-slave-backup备份从库时--slave-info 会记录当前复制位点--safe-slave-backup 会在备份期间暂停 SQL 线程防止从库在备份过程中应用新的 relay log保证备份数据一致性。这个参数在搭建新从库或重建故障从库时特别有用。还有一些高频但容易忽略的参数--no-server-version-check --streamtar --history--no-server-version-check 用于跳过版本检查但我建议只在确认版本兼容后使用--streamtar 可以把备份输出成 tar 流配合管道直接推到远程存储--history 把备份历史记录到 Percona 的 history 表里后面做监控很方便。3. 实操全流程全量备份、增量备份和恢复演练3.1 全量备份的标准命令与输出解读环境假设MySQL 8.0 实例跑在本机 3306 端口datadir 是默认的 /var/lib/mysql备份账号 backup_user 权限已按官方要求授权。现在执行一次全量备份mkdir -p /backup/full/$(date %F) chown backupuser:backupuser /backup/full sudo -u backupuser xtrabackup \ --backup \ --target-dir/backup/full/$(date %F) \ --userbackup_user \ --passwordYourPassword \ --socket/tmp/mysql.sock \ --parallel4 \ --compress跑起来之后日志会持续输出正在复制哪个表空间、运行到多少字节。大概长这样[00] ...done [01] Copying /var/lib/mysql/mysql.ibd to /backup/full/20250301/mysql.ibd [01] ...done ... [100] 2025-03-01T02:00:10.12345608:00 Backup created in directory /backup/full/20250301/ of size 5.2GB [100] 2025-03-01T02:00:10.13010008:00 MySQL binlog position: filename mysql-bin.000012, position 987654 [100] 2025-03-01T02:00:10.13010008:00 completed OK!看到 completed OK! 就说明备份成功了。这时候去备份目录里看最重要的几个文件是xtrabackup_checkpoints记录备份的 from_lsn、to_lsn、备份类型增量备份全靠它。xtrabackup_info包含实例信息、备份工具版本、binlog 位置等排查问题时很有用。xtrabackup_binlog_info记录备份时 binlog 文件名和 position日后做时间点恢复要参考它。很多新手备份完不看这些文件等恢复时出问题才开始查我建议每次备份脚本里直接把 xtrabackup_checkpoints 和 xtrabackup_binlog_info 打印到日志这样哪天需要恢复一眼就能找到对应的 binlog 位点。3.2 增量备份的正确姿势增量备份的含义不是“备份变化的数据文件”而是“从上一次备份的 LSN 到当前时刻新增的 redo log 和数据页”。所以它必须指定一个基准目录。假设周一做了全量备份目录是 /backup/full/20250301。周二凌晨想做第一次增量命令如下sudo -u backupuser xtrabackup \ --backup \ --target-dir/backup/inc/20250302 \ --incremental-basedir/backup/full/20250301 \ --userbackup_user \ --passwordYourPassword \ --socket/tmp/mysql.sock \ --parallel4 \ --compress周三的第二次增量就基于周二的增量--incremental-basedir 改成 /backup/inc/20250302。这样形成一条“全量 - 增量1 - 增量2”的链条。为什么增量不能直接拿来做恢复因为每个增量目录里只存了“和上一次备份相比变化的部分”单独读它数据文件不完整。需要先把全量备份 prepare再按顺序把增量“合并”进全量备份最后得到一个完整的、包含所有到最新时刻数据的全量目录。这个合并操作后面恢复小节里会演示。还有一点要提醒binlog 每天也在产生Xtrabackup 的增量备份管理的是 InnoDB 文件层面的变化跟 binlog 不是一个东西。如果你想做精确到秒级的时间点恢复传统做法是拿 Xtrabackup 的全备 增量合并好的目录 从 last backup 时刻开始的 binlog 一起恢复两者配合才能把恢复点推进到事故前的那一秒。3.3 恢复的完整链路prepare 和 copy-back恢复是备份的最终目的这块我建议每个 DBA 至少在自己测试环境全流程演练三遍以上。恢复分两步先 prepare再 copy-back。prepare 的目的是把备份时残留的 redo log 回放进去让数据文件变得一致。对纯全量备份命令十分简单sudo -u backupuser xtrabackup --prepare --target-dir/backup/full/20250301看到 completed OK! 才算 prepare 成功。prepare 之后备份目录里的数据文件已经是“可启动”状态。如果有增量备份顺序就不一样了。先把全量 prepare 到“只应用日志、不结束”的阶段再按顺序把每个增量合并进去。命令大概是xtrabackup --prepare --apply-log-only --target-dir/backup/full/20250301 xtrabackup --prepare --apply-log-only --target-dir/backup/full/20250301 \ --incremental-dir/backup/inc/20250302 xtrabackup --prepare --apply-log-only --target-dir/backup/full/20250301 \ --incremental-dir/backup/inc/20250303注意最后一次 prepare 一般不加 --apply-log-only因为要执行最终的 rollback 阶段让数据文件处于完全可用的状态。顺序错了或者漏了哪一步恢复出来的库可能缺数据甚至起不来。prepare 完成后的 copy-back核心是把备份目录里的文件拷回 MySQL 的 datadir。此时数据库必须处于停止状态而且原 datadir 要么清空、要么改名备份。我习惯先做一步备份旧目录systemctl stop mysql mv /var/lib/mysql /var/lib/mysql_bak_$(date %F) mkdir /var/lib/mysql chown mysql:mysql /var/lib/mysql sudo -u backupuser xtrabackup --copy-back --target-dir/backup/full/20250301 chown -R mysql:mysql /var/lib/mysql systemctl start mysql这里最关键的是权限。copy-back 后如果忘了 chownMySQL 会因为没有权限读取数据文件而启动失败日志里报一堆 Permission denied。修复也简单chown -R mysql:mysql 后再 start 就行。3.4 写一个可用的备份脚本脚本不复杂但有几个点必须考虑进去记录日志、检查 completed OK、清理过期备份、失败告警。下面这个是我压过生产环境的简化版本逻辑上可以直接套用#!/bin/bash # 全量增量备份脚本依赖 xtrabackup 8.0 export PATH/usr/local/bin:/usr/bin:/bin BACKUP_USERbackup_user BACKUP_PASSYourStrongPassword SOCKET/tmp/mysql.sock BASE_DIR/backup DATE$(date %F) HOUR$(date %H) LOG_FILE/var/log/xtrabackup_${DATE}_${HOUR}.log # 周一做全量其他时间做增量 if [ $(date %u) 1 ]; then TARGET${BASE_DIR}/full/${DATE} CMD_OPTS--backup --target-dir${TARGET} else INC_LAST$(ls -td ${BASE_DIR}/full/* ${BASE_DIR}/inc/* 2/dev/null | head -1) TARGET${BASE_DIR}/inc/${DATE}_${HOUR} CMD_OPTS--backup --target-dir${TARGET} --incremental-basedir${INC_LAST} fi echo $(date) start ${LOG_FILE} xtrabackup ${CMD_OPTS} \ --user${BACKUP_USER} --password${BACKUP_PASS} --socket${SOCKET} \ --parallel4 --compress ${LOG_FILE} 21 if [ $? -eq 0 ]; then echo OK ${LOG_FILE} else echo FAILED ${LOG_FILE} # 这里接企业微信/钉钉/邮件告警脚本退出 exit 1 fi # 清理 7 天前的备份 find ${BASE_DIR} -maxdepth 2 -type d -mtime 7 -exec rm -rf {} \;这个脚本里“周一全量、其他天增量”的策略只是参考你也可以根据业务增长和备份窗口改成“每天全量每小时增量”。想更稳妥的话把 --streamtar 加上管道推到对象存储或者另一台备份机器防止本地磁盘和数据库一起挂掉时备份也完蛋。异地备份这件事等真碰上机房级故障才会发现有多重要。4. 常见问题与排查技巧实录4.1 备份失败时的排查思路Xtrabackup 备份失败大概就几类原因按出现频率排第一是权限不足。备份账号至少要拥有 RELOAD、PROCESS、LOCK TABLES、REPLICATION CLIENT 权限MySQL 8.0 下还需要 BACKUP_ADMIN 权限。老版本用了 LOCK INSTANCE FOR BACKUP 之类的接口新版本权限要求还会更高一点。报错常见于“The user specified does not have the correct privileges”。解决方法是按官方文档重新授权别图省事直接给 all privileges。第二是磁盘空间不够。全量备份加上 redo log 复制体积会短暂超过实际数据量。我一次失败的教训是备份库 500G以为磁盘还剩 600G 就够了结果备份目录被 qpress 压缩前的临时文件和 redo 日志塞爆直接 out of space。建议把空间预留到备份目录体积的 1.5 倍起再考虑是否加 --compress。第三是版本不匹配。这个在 2.1 里说过了最容易发生在升级数据库后忘记同步升级 Xtrabackup。保险做法是每次 MySQL 升级时先把备份跑到一个新目录验证一遍通过后再切正式备份策略。第四是网络或连接问题。TCP 连接备库时网络抖动会导致备份中断socket 模式则有可能因为权限不对无法访问 socket 文件。日志里通常会有 “Got error 2002” 或 “Cant connect”按常规连接问题排查即可。碰到报错先不要慌第一步永远是看完整日志的错误行而不是只看最后几行。xtrabackup 的日志已经把很多提示写得很直白比如 io error、No space left on device 这种一眼就能定位的直接按提示处理。4.2 恢复时最容易踩的几个坑恢复环节的坑比备份多得多这里列几个我亲历过的一是少执行 prepare 或把增量顺序搞错。前面强调过多次未 prepare 的备份直接拷贝回去实例大概率起不来而增量合并顺序反了数据会是乱的而且很难发现因为实例能正常启动但你并不知道缺了哪些最新提交。所以增量恢复后我会刻意对账一些关键表的行数或最新时间戳而不是只看实例能启动就认为恢复成功。二是 copy-back 时原 datadir 没清干净。MySQL 启动时会扫描 datadir 下的文件旧文件和新文件交错很容易出现表空间 ID 冲突报错 “Tablespace ... exists at path ...”。我现在的习惯是干脆把整个旧 datadir 改名保留再重建一个空目录利落又安全。三是权限和属主问题。copy-back 默认以执行命令的用户身份写入文件所以如果用了 backupuser 执行 copy-back文件属主就全是 backupusermysqld 进程读不了。解决办法是一律在启动 MySQL 前 chown -R mysql:mysql datadir。四是恢复出来的实例 binlog 位点和预期对不上。如果你需要做时间点恢复恢复完基础备份后还要把从备份点到故障点的 binlog 补进来。很多人恢复完基础备份就直接启库发现数据只到备份时刻没有后续的 binlog 增量于是误以为数据丢了。要理解物理备份还原的是“备份那一瞬间”的数据库状态之后的写入要想找回来必须靠 binlog 继续推进。4.3 备份系统的监控与演练心得备份做完只是开始整个备份系统如果没有监控和定期演练就跟没有备份没什么区别。我建议至少做到三件事状态监控在备份脚本里把成功/失败结果写入一个状态表或日志文件再用监控系统Zabbix、Prometheus 之类定时检查。最简单的做法是备份脚本失败时发送告警但千万别忽略“备份成功但文件损坏”的情况所以定期做恢复演练才是兜底手段。恢复演练我所在的团队规定每个月至少做一次全量恢复演练把最近一个成功的备份恢复到测试实例上检查关键表数据行数和最新更新时间。不要嫌麻烦真正遇到故障时熟练的操作流程能把恢复时间从小时级压缩到分钟级。备份文件保留策略全量备份保留周期、增量备份保留周期、异地副本保留周期这三条要分别设定。合理的默认值是全量保留 30 天、增量保留 14 天、异地副本保留 7 天具体按业务和数据合规需求调整。别舍不得删老备份存储成本会一直膨胀但也不要过早删最尴尬的是业务要找回三个月前某条数据你手里只有一周的备份。我自己在把整套流程跑通后最深的体会是物理热备真正难的不是第一次把命令跑通而是把备份、恢复、监控、演练串成一套可重复执行的流程。Xtrabackup 把数据文件处理得干净、稳定但最终决定业务恢复效率的还是你有没有在风平浪静的时候把恢复这条路完整走过一遍。建议拿到这篇文章的读者今天就在测试环境把全量、增量、恢复各跑一次跑通了你心里那块石头才能真正落地。