备份前必须确认的 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 或忽略目录权限。
