直接cp或tar运行中的mysql数据目录会导致备份不可恢复，因文件与内存脏页不一致；必须停机或用percona xtrabackup热备，且恢复时需清空datadir并修正权限。
直接 cp 或 tar 数据目录会丢数据
MySQL 运行时，ib_logfile0、ibdata1、表空间文件（如 test/user.ibd）和内存中的脏页可能不一致。直接 cp 或 tar 会导致备份不可恢复——常见现象是恢复后 MySQL 启动失败，报错 InnoDB: Database page corruption 或 Tablespace is missing。
除非 MySQL 已彻底关闭（systemctl stop mysql 且确认无残留进程），否则不能直接拷贝。
- 用
ps aux | grep mysqld确认进程已退出 - 检查
pid_file路径（通常在/var/run/mysqld/mysqld.pid）是否还存在 - 注意：即使执行了
mysqladmin shutdown，某些配置下仍可能残留mysqld_safe进程
mysqldump 不是物理备份，别混淆
mysqldump 输出的是 SQL 文本，属于逻辑备份。它不复制 .ibd 或 ib_logfile*，也不能跳过锁表或事务一致性校验。你想要的是“原样拷贝文件”，那 mysqldump 就不是解法。
真正做物理备份的工具只有两类：停机拷贝（上一条）或支持热备的专用工具。
- 热备必须依赖 InnoDB 的崩溃恢复机制，所以要求 MySQL 开启
innodb_file_per_table=ON -
myisam表无法热备，哪怕加FLUSH TABLES WITH READ LOCK也不保险（锁可能被复制线程绕过） - 如果用了
general_log或slow_query_log文件输出到数据目录，它们也会被一起拷走——但这些日志文件不属于数据库状态，恢复时应剔除
Percona XtraBackup 是唯一靠谱的热物理备份方案
开源、免费、专为 InnoDB 设计，能一边跑着 MySQL 一边把数据文件+日志完整抓出来，并自动重放（apply-log）保证一致性。比手动 cp 多了三步关键动作：记录 binlog 位置、拷贝期间持续捕获 redo 日志、恢复前回滚未提交事务。
典型流程：
- 安装：
apt install percona-xtrabackup-80（Debian/Ubuntu）或yum install percona-xtrabackup-80（CentOS/RHEL） - 备份：
xtrabackup --backup --target-dir=/backup/20240415 --user=root --password=xxx - 准备：
xtrabackup --prepare --target-dir=/backup/20240415（这步必须做，否则恢复会失败） - 恢复：停 MySQL → 清空
datadir→xtrabackup --copy-back --target-dir=/backup/20240415→ 改权限chown -R mysql:mysql /var/lib/mysql
注意：xtrabackup 8.0 版本不兼容 MySQL 5.7，反之亦然；备份用户需有 RELOAD、PROCESS、LOCK TABLES 权限。
恢复时最容易被忽略的两个点
一是权限没改回来：cp 或 xtrabackup --copy-back 后，文件属主还是 root，MySQL 启动时读不到 ibdata1，报错 Permission denied；二是没清干净旧数据：如果只覆盖部分文件（比如漏删 mysql/ 子目录），InnoDB 初始化会卡在 Opening tables 阶段，日志里反复出现 Waiting for table metadata lock。
安全做法永远是：停服务 → rm -rf /var/lib/mysql/* → 再 copy-back → chown -R mysql:mysql /var/lib/mysql → 启动。
