离线备份不应使用XtraBackup，因其--backup模式依赖MySQL在线运行；停库后应直接tar打包数据目录，安全、快速、可控。
离线物理备份不是XtraBackup的设计目标，强行停库后用它备份反而引入多余风险；真要离线，直接tar打包更安全、更快、更可控。
为什么别用 xtrabackup --backup 做离线备份
XtraBackup 的 --backup 模式默认依赖 MySQL 实例在线——它需要连接 mysqld 获取 datadir、读取 performance_schema.log_status、执行 LOCK INSTANCE FOR BACKUP 等操作。即使你先停掉 mysqld，xtrabackup --backup 仍会报错退出，典型错误是：
Failed to connect to MySQL server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'Cannot open /proc/$(pidof mysqld)/fd: No such file or directory- 或卡在等待
log_status表响应，最终超时
它的底层逻辑就是为热备设计的：一边拷文件，一边追 redo log。离线状态下这套机制既无意义，又不可靠。
离线场景下真正该用的命令是 tar + rsync
MySQL 8.0 的数据目录（/var/lib/mysql）本身已是完整物理快照，只要确保 mysqld 已完全停止（systemctl is-active mysqld 返回 inactive），就可直接归档：
- 用
tar -cf /backup/mysql_$(date +%F).tar /var/lib/mysql打包，加--use-compress-program=pigz可并行压缩 - 若需增量归档，改用
rsync -a --delete --link-dest=/backup/mysql_latest /var/lib/mysql /backup/mysql_$(date +%F) - 务必校验：
tar -tf /backup/mysql_2026-05-10.tar | head -20确认包含ibdata1、mysql/、sys/等关键路径
这种方式跳过所有 XtraBackup 的元数据协调逻辑，不依赖任何 MySQL 进程状态，恢复时也只需解压覆盖原目录（注意权限：用户组必须为 mysql:mysql）。
如果硬要用 xtrabackup 处理已停库的数据目录
极少数运维流程强制要求“统一调用 xtrabackup 命令”，此时只能绕过连接检查，用 --no-server 模式手动指定路径：
- 先确认 mysqld 确实已停：
systemctl stop mysqld && ss -tlnp | grep :3306应无输出 - 运行：
xtrabackup --no-server --backup --target-dir=/backup/full_offline --datadir=/var/lib/mysql - 该命令不会 prepare，也不会拷 binlog 或锁实例，只做裸文件复制；后续恢复前必须手动
xtrabackup --prepare --target-dir=/backup/full_offline - 风险点：
--no-server跳过所有一致性校验，若停库前未正常关闭（如 kill -9），ib_logfile0可能残留未刷盘事务，prepare 阶段会失败
这种用法在 Percona 官方文档中属于非支持路径（unsupported path），仅用于迁移或调试，不应纳入生产备份脚本。
真正容易被忽略的是：离线备份的“一致性”不来自工具，而来自 MySQL 自身的 shutdown 流程。只要 mysqld --shutdown 成功返回，ibdata1 和 .ibd 就是可恢复的。XtraBackup 在这里不是加分项，而是干扰项。
