【MySQL】XtraBackup 全量备份还原操作指南（MySQL 5.7 / 8.0 通用）

📌 重要前提认知（操作前必读）

在执行以下恢复操作前，请务必了解 XtraBackup 的工作原理与限制：

🔍 XtraBackup 是全实例物理备份工具

默认行为 ：XtraBackup 执行的是 整个 MySQL 实例的物理备份 ，直接复制 datadir 下的所有数据文件（如 .ibd、ibdata1、.MYD、.MYI 等）。
不区分库类型 ：无论是系统库（mysql、sys、performance_schema）还是业务库，只要存在于数据目录中且使用支持的存储引擎（主要是 InnoDB/XtraDB），都会被完整备份。
恢复即全实例还原 ：恢复后得到的是一个与备份时刻完全一致的 MySQL 实例，无法仅恢复单个数据库。

✅ 恢复后包含的内容

内容	是否包含	说明
`mysql` 系统库	✅ 是	包含用户账号、权限、存储过程、函数等元数据
`performance_schema`	⚠️ 部分	表结构会恢复，但运行时性能数据不会持久化（启动后重新采集）
`sys` 库	✅ 是	视图、函数等对象会被完整恢复
所有业务库（InnoDB/MyISAM）	✅ 是	数据和表结构完整保留
二进制日志（binlog）位置	✅ 是	备份目录中包含 `xtrabackup_binlog_info` 文件，记录了备份结束时的 binlog 文件名和位置，可用于搭建主从复制

❗ 结论：这是 "全库还原"，不是 "单库还原"。

❓ 能否只备份或还原某个业务库？

❌ XtraBackup 不支持单库物理备份/恢复。这是物理备份工具的固有限制。
✅ 替代方案 ：若只需保护特定业务库，应使用逻辑备份工具，例如：mysqldump、mydumper

💡 建议：

使用 XtraBackup 适用于 整实例灾难恢复、主从搭建、快速克隆环境 等场景。

使用逻辑备份适用于 跨版本迁移、单库导出、开发测试数据提取 等需求。

操作流程：XtraBackup 全量恢复步骤

⚠️ 前提：已安装 Percona XtraBackup，且备份为压缩格式（含 .qp 文件）。

一、明确还原目标与所需备份

在动手前，必须回答两个核心问题：

1. 要恢复到哪个时间点？

2. 需要哪些备份文件才能达到该时间点？

1.1 理解当前备份策略

注意：当前备份策略来源于前面的两篇文章，备份的脚步也在里头，需要可移步获取。

1.从零搭建高性能、高可用的 MySQL 5.7 环境（附 XtraBackup 自动备份方案）

2.从零搭建高性能、高可用的 MySQL 8.0 环境（附 XtraBackup 自动备份方案）

项目	说明
备份根目录	`/mydata/backup/xtrabackup`
全量备份	每周日执行一次
- `full/`	存放最近一次全备（最新周日）
- `fullx/`	存放历史全备，目录名格式为 `MMDD`（如 `1120` = 11月20日）
增量备份	周一至周六每日执行一次
- `incr/`	所有增备按 `MMDD` 命名（如 `0812` = 8月12日）
备份日志	`/mydata/script/backup/log/`，日志文件名如 `xtrabackup_20220526-100334.log`
保留周期	默认保留 1 个月

1.2 根据恢复时间点确定备份组合

恢复时间	所需备份
周日（全备日）	仅需对应周日的全量备份
周一至周六（增备日）	需上周日全备 + 当天增量备份

💡 示例：要恢复到 8 月 12 日（周三），则需：

全备：8 月 6 日（上周日）的 full/ 或 fullx/0806

增备：incr/0812

1.3 验证备份链完整性（LSN 校验）

增量备份必须基于正确的全备。通过 LSN（日志序列号）验证：

bash 复制代码

# 查看增量备份起点 LSN
cat /mydata/backup/xtrabackup/incr/0812/xtrabackup_checkpoints
# 输出：from_lsn = 10645041

# 查看全备终点 LSN
cat /mydata/backup/xtrabackup/full/xtrabackup_checkpoints
# 输出：to_lsn = 10645041

✅ 校验通过条件 ：全备.to_lsn == 增备.from_lsn

1.4 验证备份有效性

确保所选备份已成功完成：

bash 复制代码

# 检查对应日期的备份日志
grep'completed OK' /mydata/script/backup/log/xtrabackup_20220812-*.log

✅ 若输出包含 completed OK!，则备份有效。

二、准备备份数据（解压与合并）

根据第1章确定的场景，准备可恢复的数据集。

⚠️ 所有操作均在备份副本上进行，不要直接操作原始备份！

2.1 场景一：仅需全量备份（恢复到周日）

复制代码

# 1. 复制备份到临时目录（保护原始）
cp -r /mydata/backup/xtrabackup/full /mydata/temp_bak/

# 2. 解压（若为压缩格式）
xtrabackup --parallel=2 --decompress --target-dir=/mydata/temp_bak

# 3. 应用 redo log，完成一致性准备
xtrabackup --parallel=2 --prepare --target-dir=/mydata/temp_bak

2.2 场景二：需全备 + 增量备份（恢复到工作日）

复制代码

# 1. 复制全备和增备到临时目录
cp -r /mydata/backup/xtrabackup/full /mydata/temp_bak/
cp -r /mydata/backup/xtrabackup/incr/0812 /mydata/temp_incr/

# 2. 解压全备
xtrabackup --parallel=2 --decompress --target-dir=/mydata/temp_bak

# 3. 解压增量
xtrabackup --parallel=2 --decompress --target-dir=/mydata/temp_incr

# 4. 合并增量到全备
xtrabackup --parallel=2 --prepare\
  --incremental-dir=/mydata/temp_incr\
  --target-dir=/mydata/temp_bak
  
# 5. ⭐ 最终 prepare（必须！）
xtrabackup --parallel=2 --prepare --target-dir=/mydata/temp_bak

说明：

-decompress：解压由 -compress 生成的 .qp 压缩文件（如 ibdata1.qp、*.ibd.qp 等）。

-parallel=2：使用 2 个线程并行解压，加速处理（可根据 CPU 核数调整）。

注意：解压后原 .qp 文件仍保留，可手动删除以节省空间（rm -f *.qp）。

-prepare：重放备份期间产生的 InnoDB redo log，将数据页恢复到崩溃一致状态（Crash-consistent）。

成功后会显示 Shutdown completed 或 InnoDB: Shutdown completed。

三、执行还原与启动验证

3.1 停止 MySQL 服务

bash 复制代码

systemctl stop mysqld

说明：必须确保 MySQL 完全停止，才能安全替换数据目录。

3.2 备份当前数据目录（强烈推荐）

bash 复制代码

mv /mydata/data /mydata/data_bak
mkdir /mydata/data

说明：保留现有数据作为紧急回滚方案。

3.3 执行数据还原

bash 复制代码

xtrabackup --copy-back --target-dir=/mydata/temp_bak/full

说明：将准备好的数据文件复制到 datadir（即 /mydata/data）。

3.4. 修复文件权限

bash 复制代码

chown -R mysql:mysql /mydata/data
chmod -R 750 /mydata/data

说明：

XtraBackup 以当前用户身份复制文件，通常不是 mysql 用户。

必须将 /mydata/data 及其所有子文件归属给 mysql 用户和组，确保 MySQL 进程有权限读写数据文件，否则 MySQL 启动失败。

3.5. 启动 MySQL 并验证

复制代码

systemctl start mysqld

验证建议：

sql 复制代码

SHOW DATABASES;
SELECT USER, HOST FROM mysql.user;-- 检查账号是否恢复
SHOW MASTER STATUS;-- 检查 binlog 位置（对比 xtrabackup_binlog_info）

✅ **恢复完成！**请根据业务需求决定是否清理临时目录（/mydata/temp_bak/）和旧数据备份（/mydata/data_bak/）。

🔒 安全提示：生产环境操作前务必在测试环境验证流程，并确保有完整的回滚预案。