能实现，但必须满足两个硬条件：mysql用innodb/xtradb引擎，且备份用户具备backup_admin、reload、lock tables、replication client权限；缺一则导致xtrabackup --backup卡住或报error 1227权限拒绝。
能直接用 xtrabackup 做热备，但必须满足两个硬条件：MySQL 实例用的是 InnoDB/XtraDB 引擎，且备份用户有 BACKUP_ADMIN、RELOAD、LOCK TABLES、REPLICATION CLIENT 权限。
为什么 xtrabackup --backup 会卡住或报错权限不足
常见现象是命令执行后长时间无响应，或直接报 ERROR 1227 (42501): Access denied。这不是网络或磁盘问题，而是权限缺失或引擎不匹配。
- MySQL 8.0+ 必须显式授予
BACKUP_ADMIN，仅SELECT或PROCESS不够 - MyISAM 表存在时，
xtrabackup单独运行会失败；此时应改用innobackupex（已弃用但兼容旧环境），或确保只备份 InnoDB 库（加--databases限定） - 如果实例启用了
skip_name_resolve，--host=127.0.0.1可能无法匹配授权用户，建议统一用--host=localhost并确认用户是'bkpuser'@'localhost'
xtrabackup --backup 的最小可用命令与关键参数
不要一上来就堆参数。先跑通最简流程，再加定制：
- 基础命令：
xtrabackup --backup --target-dir=/backup/full_$(date +%Y%m%d) --user=bkpuser --password=xxx --port=3306 -
--parallel=4：加速数据页拷贝，但别超过 CPU 核数 × 2，否则 IO 争抢反而拖慢 -
--compress：边拷贝边压缩（需提前装qpress），但会增加 CPU 开销，TB 级备份慎用 -
--no-timestamp：避免自动生成时间子目录，方便脚本管理路径 - 切勿省略
--target-dir，它必须是空目录，且xtrabackup进程对其有写权限
备份后必须执行 --prepare，否则还原必失败
刚备份出来的目录不能直接恢复——它处于“未崩溃恢复”状态，就像 MySQL 异常宕机后的数据文件。跳过 --prepare 直接 --copy-back 会导致启动失败，报错类似 InnoDB: Database page corruption。
- 全量备份准备：
xtrabackup --prepare --target-dir=/backup/full_20260602 - 增量备份准备分两步：先 prepare 全备（加
--apply-log-only），再 merge 增量（同样加该参数），最后对最终目录做一次不带该参数的 prepare -
--apply-log-only的作用是跳过回滚未提交事务，为后续增量合并留出空间；漏掉它，增量 merge 会报LSN mismatch - prepare 过程不依赖 MySQL 服务运行，但耗时长（尤其大库），建议在备用机上执行
还原时最易忽略的三件事
还原不是复制粘贴完就完事。三个操作缺一不可，顺序也不能错：
- MySQL 必须完全停止：
systemctl stop mysqld，哪怕只是临时停几秒；强行覆盖运行中实例的数据目录会损坏文件系统 -
--copy-back后，/var/lib/mysql目录所有权仍是 root，必须手动执行：chown -R mysql:mysql /var/lib/mysql，否则启动报Can't start server: cannot resolve table names - 若原库启用了
innodb_file_per_table=OFF，备份中ibdata1是共享表空间，还原后需确认my.cnf中该配置值一致，否则启动失败
LSN 对齐和 redo log 回放是 xtrabackup 的底层契约，所有命令都在围绕这个机制运转。不理解 LSN 就调参数，等于在数据库的事务日志上蒙眼走钢丝。
