使用 Percona XtraBackup 进行备份、恢复和 PITR
MySQL难度: 中级耗时: 45–90 分钟使用 Percona XtraBackup 进行物理备份：安装匹配版本的 XtraBackup、创建使用 auth_socket 的备份用户、编写压缩/加密的 full + incremental 备份脚本、用 systemd timer 或 cron 调度、复制 binlog 并进行恢复演练。场景卡片涵盖完整恢复、从 incremental 链恢复、恢复到指定时间点 (PITR)、单表恢复、从备份搭建 replica 以及恢复到另一台服务器。大型数据库的日常备份和灾难恢复使用本指南；迁移、单个 schema/表导出或跨版本迁移请使用逻辑备份 (mysqldump / MySQL Shell) 指南。
架构: 1 台服务器（单机、source、replica 或 InnoDB Cluster secondary）；备份存储为本地磁盘或 NFS
场景
- 配置备份、调度并测试恢复（完整流程） — 安装 XtraBackup、创建备份用户、编写 full + incremental 备份脚本、配置调度并进行一次恢复演练（含 PITR）。首次部署请选择此项。备份在服务器运行时进行；无停机，只增加磁盘/CPU 负载。
- 完整恢复：恢复到最新的 full 备份 — 数据目录丢失/损坏或服务器无法启动；恢复到链中的 full 备份即可。恢复期间 MySQL 一直处于关闭状态。
- 从 full + incremental 链恢复（到最新的 incremental） — 需要恢复到最新 incremental 备份的时间点（或您选择的某个 incremental）；incremental 按顺序用 --apply-log-only 应用到 full 之上。恢复期间 MySQL 一直处于关闭状态。
- 恢复到指定时间点 (PITR)：错误的 DELETE / DROP 之前 — 误删除或被破坏的数据：恢复最新备份，然后应用 binlog，直到错误 transaction 之前（按时间、位置或 GTID）。恢复期间 MySQL 一直关闭，错误发生之后的写入也会被回退；如果只影响一张表，请先考虑单表场景。
- 恢复单表 (--export + IMPORT TABLESPACE) — 只需要某张表在备份中的版本；无需恢复整个服务器，从备份中将该表以 t_restore 名称导入，再从中修复数据。服务器保持运行。
- 从备份搭建新的 replica — 希望用现有的 XtraBackup 备份（而不是通过网络 clone）准备一个新的（或重建的）replica 并连接到 source（数据量大、source 负载）。source 不受影响；目标服务器的数据将被替换。
- 将备份恢复到另一台服务器（迁移、测试、克隆） — 需要在测试/开发服务器上打开生产备份、迁移服务器，或在另一台服务器上验证备份确实可以恢复。源服务器不受影响。
开始之前
- MySQL … 正在运行（如果使用 DBAtlas MySQL 单机安装指南安装，路径相同）；操作系统 root 用户可以用 mysql 命令无密码连接（auth_socket 或 ~/.mylogin.cnf）。
- 备份目录 … 位于独立的磁盘/NFS 上，空间至少为（数据大小 × 链数）…（zstd 通常可压缩到 1/3–1/6）…。恢复时 … 下需要至少两倍数据大小的可用空间（解压 + prepare）。
- 已启用 binary log 和 GTID（用于 PITR 和 incremental 一致性）。
- 服务器可以通过 HTTPS 访问 repo.percona.com，或已配置内部镜像。
- 已准备好服务器之外的安全位置（保险柜、密码管理器）来保存加密密钥副本。密钥丢失后备份将无法打开。
- 最好有一台单独的测试服务器用于恢复测试（使用相同 MySQL 版本和相同 my.cnf 安装）。恢复步骤会替换其所在服务器的数据目录。
- 此服务器是健康的 replica：IO 和 SQL thread 均为 Yes，延迟很低。如果要复制 binlog (PITR)，必须启用 log_replica_updates（8.x 默认启用）；否则 replica 的 binlog 不包含来自 source 的 transaction。
- 此服务器是 InnoDB Cluster 成员，当前为 SECONDARY / ONLINE。备份调度在此成员上；如果该成员以后变为 primary，脚本会记录警告并仍然执行备份。
- 要恢复的备份链位于 … 下…（在 … 服务器上）…且完整：full 和要使用的 incremental，以及 -lsn 元数据目录…；加密密钥位于 ……。
- 此服务器上已安装 MySQL … 和 XtraBackup …；MySQL 小版本与执行备份的服务器相同或更新（备份的 server_version 值会在诊断步骤中显示）。
- …目标服务器上没有需要保留的数据：数据目录将被备份替换（旧目录被移到 .old-<time>）。…维护窗口和应用停机已获批准：恢复期间 MySQL 处于关闭状态；应用不得连接此服务器。…
- 该表为 InnoDB，且在 innodb_file_per_table = ON（8.x 默认）下有独立的 .ibd 文件；自备份以来表结构（列、索引）没有变化。服务器保持运行。
指南阶段
- 安装 XtraBackup — 添加 Percona 仓库 · 安装 XtraBackup
- 备份用户和密钥 — 检查 auth_socket 插件 · 创建备份用户 · 测试连接 · 创建加密密钥
- 备份脚本和调度 — 创建备份目录 · 编写备份脚本 · 赋予脚本执行权限 · 执行首次 full 备份 · 尝试增量备份 · 编写 systemd 服务 …
- 恢复 (restore) — 将链复制到工作目录 · 解密 / 解压 · 准备 full 备份 (prepare, apply-log-only) · 按顺序应用 incremental · 最终 prepare · 停止 MySQL，将现有数据移开 …
- 时间点恢复 (PITR) — 确定目标时刻 · 将 binlog 应用到目标时间 · 验证结果并做新备份
- 清理 — 删除移开的数据和工作目录
- 1. 诊断：使用哪个备份、哪种方法？ — 检查服务器状态和版本 · 列出备份链及其内容
- 2. 安全网 — 记录当前状态和配置
- 3. 实施：准备备份 — 将链复制到工作目录 · 将链复制到工作目录 · 解密 / 解压 · 准备 full 备份 (prepare, apply-log-only) · 按顺序应用 incremental · 最终 prepare
- 3. 实施：恢复数据 — 停止 MySQL，将现有数据移开 · 将备份复制到数据目录 (copy-back) · 启动 MySQL 并验证 · 检查从备份恢复的复制配置
- 3. 实施：应用 binlog 到目标点 (PITR) — 确认错误的 transaction 和目标点 · 应用 binlog 到目标点
- 4. 验证 — 确认错误 transaction 已被撤销 · 验证数据
- 5. 后续 — 做一次新的 full 备份 · 删除移开的数据和工作目录 · 根本原因和拓扑
- 1. 诊断：表和备份是否满足条件？ — 显示表的当前状态和结构 · 列出备份链及其内容
- 2. 安全网 — 备份表的当前状态
- 3. 实施：用 --export 准备备份 — 将链复制到工作目录 · 解密 / 解压 · 准备 full 备份 (prepare, apply-log-only) · 按顺序应用 incremental · 最终 prepare (--export)
- 3. 实施：将表导入中间表 — 创建中间表并丢弃其表空间 · 从备份复制文件并导入 (IMPORT TABLESPACE)
- 4. 验证 — 检查中间表并与原表比较
- 5. 后续：复制数据并清理 — 将所需的行复制到原表 · 删除中间表和工作目录
- 1. 诊断：目标服务器和备份是否满足条件？ — 检查目标服务器的版本、标识和磁盘 · 列出备份链及其内容 (…)
- 2. 安全网 — 记录当前状态和配置
- 3. 实施：拉取并准备备份 — 从备份服务器拉取链 · 将链复制到工作目录 · 解密 / 解压 · 准备 full 备份 (prepare, apply-log-only) · 按顺序应用 incremental · 最终 prepare
- 3. 实施：恢复数据 — 停止 MySQL，将现有数据移开 · 将备份复制到数据目录 (copy-back) · 启动 MySQL 并验证 · 检查从备份恢复的复制配置
- 3. 实施：从备份的位置开始复制 — 确定起点 · 配置并启动复制
- 4. 验证 — 验证数据
- 5. 后续 — 删除移开的数据和工作目录 · 让服务器以新角色投入使用