xtrabackup 不该用于冷备份，因其设计依赖运行中的 mysql 实例以获取 redo log 和 checkpoint 信息；数据库停止时会连接失败、无法读取关键元数据，导致备份不可恢复。
Percona 工具本身不用于冷备份——xtrabackup 是热备工具，冷备直接用 cp 或 tar 就够了，强行用它反而增加复杂度和风险。
为什么 xtrabackup 不该用于冷备份
Percona XtraBackup 的设计目标是「不锁表、不停服」地做物理备份，核心机制依赖于 InnoDB 的 redo log 和 checkpoint 信息，在数据库运行时抓取一致性状态。一旦 MySQL 已停止：
-
xtrabackup --backup会直接报错退出，提示Can't connect to local MySQL server或类似连接失败信息 - 即使加
--no-lock和--target-dir强行指向 datadir，它也无法读取必要的事务日志元数据，生成的备份不可恢复 - 官方文档明确说明：xtrabackup 要求 mysqld 进程处于运行状态（哪怕只是部分启动）
真要冷备份，该用什么命令和顺序
冷备份本质就是停库后拷贝文件，但顺序和权限细节决定能否成功恢复：
- 先执行
systemctl stop mysqld（或mysqld_safe --shutdown），确认ps aux | grep mysqld无残留进程 - 确认 datadir 路径：查
my.cnf中的datadir，常见为/var/lib/mysql；别漏掉innodb_log_group_home_dir指向的 redo 日志目录（默认同 datadir） - 用
tar -czf /backup/mysql-$(date +%F).tar.gz -C /var/lib/ mysql/打包，必须保留相对路径，不能直接tar -C /var/lib/mysql -f ... . - 备份完再检查：
tar -tzf /backup/mysql-*.tar.gz | head -20看是否含ibdata1、ib_logfile0、各库子目录等关键文件 - 恢复时务必保证目标机器 MySQL 版本与原环境一致（特别是主版本号，如 5.7 vs 8.0），否则
ibdata1兼容性会直接导致启动失败
冷备份最容易被忽略的三个点
不是“停库→拷贝→完事”，以下三点出错，恢复时大概率卡在启动阶段：
-
my.cnf配置文件必须一并备份，尤其是innodb_page_size、lower_case_table_names、character-set-server这类影响数据解释的参数，缺失会导致表无法打开或乱码 - 如果用了 SELinux，
tar备份时要加--selinux参数（或恢复后restorecon -Rv /var/lib/mysql），否则 MySQL 启动报Permission denied却查不到原因 - 备份前没清空
mysql-bin.*和relay-log.*文件？冷备里混入旧 binlog 可能导致恢复后主从同步错位，建议停库后RESET MASTER再备份（仅适用于无主从或可重建复制的场景）
冷备份真正考验的是对 MySQL 文件结构和系统权限的理解，而不是工具调用——越简单的方法，越需要把每个路径、每个 flag、每个隐式依赖都盯死。
