xtrabackup备份前必须确认：1.mysqld进程运行且可连接；2.执行用户对数据目录有读权限、对备份路径有写权限；3.MySQL启用innodb_file_per_table=ON；备份后必须执行prepare才能恢复。
备份前必须确认的 3 个前提条件
不检查这三项，xtrabackup 很可能直接报错退出或产生不可用备份：
-
mysqld进程正在运行，且能通过mysql -u root -p正常连接（xtrabackup需要读取数据字典和事务日志） - 执行备份的系统用户（如
root或mysql）对 MySQL 数据目录（如/var/lib/mysql）有读权限，对备份目标路径有写权限 - MySQL 已启用
innodb_file_per_table = ON（非强制但强烈建议；否则恢复时无法单独还原单表，且备份体积大、校验慢）
全量备份命令与关键参数说明
最常用且安全的全量备份命令是：
xtrabackup --backup --target-dir=/backup/full_$(date +%F_%H%M%S) --user=root --password=xxx
注意几个易错点：
-
--backup是必需动作参数，漏掉会变成“准备备份”而非“执行备份” -
--target-dir必须是**空目录**，xtrabackup不会自动创建父级路径，需提前mkdir -p - 不加
--no-timestamp时，xtrabackup会在--target-dir后自动追加时间戳子目录，容易导致路径误解 - 如果 MySQL 配置了 socket 路径（如
/var/run/mysqld/mysqld.sock），需额外加--socket=/path/to/mysql.sock，否则连不上
备份后必须执行 prepare（不是可选项）
刚生成的备份是“不一致”的——因为 InnoDB 允许在备份过程中持续写入，xtrabackup 只拷贝了数据文件快照，未同步 redo log 状态。跳过 prepare 直接恢复会导致 MySQL 启动失败，报错类似：InnoDB: Database page corruption on disk。
正确做法是立即执行：
xtrabackup --prepare --target-dir=/backup/full_2024-06-15_143022
- 该过程会重放
ib_logfile中的已提交事务，并回滚未提交事务，使备份达到“一致性恢复点” - 若中途被 kill 或磁盘满，
--prepare可重复执行（只要备份目录没被破坏） - 生产环境建议加
--use-memory=2G加速（值建议设为物理内存的 25%～50%，避免 OOM）
恢复到新实例：覆盖 vs 初始化目录
恢复不是简单复制文件。MySQL 实例必须处于停止状态，且数据目录不能直接覆盖：
- 若目标是**替换现有实例**：清空原
/var/lib/mysql，再用xtrabackup --copy-back --target-dir=/backup/full_...；注意该命令默认以mysql用户权限复制，需确保用户存在且有目录所有权 - 若目标是**搭建新从库或测试库**：更稳妥的做法是先初始化空实例（
mysqld --initialize --datadir=/new/mysql），再--copy-back，最后手动修正auto.cnf中的server-uuid（避免主从冲突） -
--copy-back不会重建mysql系统库，所以恢复后首次启动前，必须chown -R mysql:mysql /var/lib/mysql，否则mysqld因权限拒绝启动
prepare 和 copy-back 是两个独立阶段，中间任何一步出错，备份就失去可用性。实际操作中，90% 的恢复失败源于跳过 prepare 或忽略目录权限。
