---
tags: [MySQL, mysqldump, XtraBackup, PITR, 备份恢复]
create time: 2026-05-16 00:00
---

# 备份与恢复

## 概述

备份是数据安全最后一道防线。本章覆盖逻辑备份（mysqldump）、物理备份（Percona XtraBackup）、以及基于 binlog 的时间点恢复（PITR）三大核心方案。

## 备份策略全景

```mermaid
flowchart LR
    subgraph "逻辑备份"
        LD["mysqldump<br/>导出 SQL"]
        LF["全量 + 增量<br/>依赖 binlog"]
    end
    
    subgraph "物理备份"
        PD["Percona XtraBackup<br/>热拷贝ibd文件"]
        PF["压缩 + 加密<br/>支持部分备份"]
    end
    
    subgraph "选择指南"
        LS["数据量 < 50GB<br/>停机窗口可接受"]
        PS["数据量 > 50GB<br/>需要 0 停机"]
    end
    
    LD --> LS
    PD --> PS
    
    style LS fill:#00B6BC,color:#fff
    style PS fill:#00D866,color:#fff
```

## mysqldump 逻辑备份

### 全量备份

```bash
# 最基础的全量备份
mysqldump -u root -p --all-databases > all_dbs_$(date +%F).sql

# 推荐的参数组合（保持一致性和完整性）
mysqldump \
  -u root -p \
  --single-transaction        # MVCC 快照，不锁表
  --flush-logs                # 切换 binlog，便于后续恢复
  --master-data=2             # 记录 binlog position（注释形式）
  --routines                  # 包含存储过程和函数
  --triggers                  # 包含触发器
  --events                    # 包含事件调度器
  --databases app_db report_db > backup_$(date +%F).sql
```

### 还原

```bash
# 全量还原
mysql -u root -p < backup_2026-05-16.sql

# 只还原某个表（先导出再导入）
mysqldump -u root -p app_db --table users > users.sql
mysql -u root -p app_db < users.sql
```

### mysqldump 的优缺点

| 优点 | 缺点 |
|------|------|
| 简单可靠，几乎不会出错 | 大库慢（导入/导出）|
| 文本格式，可读可编辑 | 导出的数据和原始可能有差异（如字符集转换）|
| 自带权限和表结构定义 | 不支持增量备份 |
| 跨版本迁移方便 | 备份期间虽然有 `--single-transaction`，但 `--flush-logs` 仍需短暂锁表 |

## Percona XtraBackup（物理备份）

### 全量备份

```bash
# 全量备份（热备，不停机）
xtrabackup --backup \
  --target-dir=/data/backups/full/ \
  --user=root --password=xxx \
  --parallel=4                    # 多线程并行拷贝
  
# 备份后的准备阶段（使备份可用于恢复）
xtrabackup --prepare --target-dir=/data/backups/full/

# 增量备份（基于上一次备份）
xtrabackup --backup \
  --target-dir=/data/backups/inc1/ \
  --incremental-basedir=/data/backups/full/ \
  --user=root --password=xxx

# 合并增量到全量（减少恢复时间）
# 先对全量做 prepare，只应用已提交的事务，不回滚未提交的
xtrabackup --prepare --target-dir=/data/backups/full/ --apply-only
# 再将增量备份合并进来
xtrabackup --prepare --target-dir=/data/backups/full/ --incremental-dir=/data/backups/inc1/

# 如果有多个增量层，依次合并
xtrabackup --prepare --target-dir=/data/backups/full/ --incremental-dir=/data/backups/inc2/
```

### 恢复

```bash
# 1. 停止 MySQL
systemctl stop mysqld

# 2. 清空数据目录（或用新目录）
rm -rf /var/lib/mysql/*

# 3. 拷贝备份数据
cp -a /data/backups/full/. /var/lib/mysql/

# 4. 设置权限
chown -R mysql:mysql /var/lib/mysql

# 5. 启动 MySQL
systemctl start mysqld
```

### XtraBackup 的优缺点

| 优点 | 缺点 |
|------|------|
| **热备份**：备份期间业务不受影响 | 学习曲线较陡 |
| 速度快：直接拷贝 ibd 文件 | 需要安装额外软件 |
| 支持增量备份 | 不能跨 major version（8.0→8.0）|
| 恢复速度远快于 mysqldump | 占用较多磁盘空间（物理拷贝）|

## PITR — 时间点恢复

结合全量备份 + binlog，可以将数据库恢复到任意精确时刻。

> [!QUESTION] 思考：如果凌晨 3 点的备份完成时 binlog position 是 `mysql-bin.000005:1234`，而 10 点误操作发生在 `mysql-bin.000006` 中，该怎么办？
> 答案是：binlog 链不能断——从 `mysql-bin.000005:1234` 开始到当前为止的所有 binlog 文件都必须保留。任何缺失都会导致 PITR 失败。

```mermaid
timeline
    title PITR 恢复流程
    00:00 : 凌晨全量备份 (XtraBackup)
    06:00 : 应用正常运行
    10:00 : ⚠️ 误删表！DELETE FROM users;
    10:01 : 检测到异常，开始恢复
    恢复过程 : 1. 恢复全量备份到 00:00
             : 2. 重放 binlog 到 09:59:59
             : 3. 跳过误操作语句
             : 4. 恢复到 10:00 之前的状态
```

```bash
# 第一步：恢复全量备份
# （前面已讲过 XtraBackup 恢复步骤）

# 第二步：找到误操作的准确位置
# 方法 A：用时间定位（推荐，最直观）
mysqlbinlog --stop-datetime='2026-05-16 09:59:59' /var/lib/mysql/mysql-bin.000006 > safe_events.sql

# 方法 B：搜索误操作语句，获取 position
mysqlbinlog /var/lib/mysql/mysql-bin.000006 | grep -B5 "DROP DATABASE\|DELETE FROM users"
# 找到对应的 DELETE 所在事务的 stop_position，在此之前停止

# 第三步：重放 binlog 到误操作之前（基于 position）
mysqlbinlog \
  --start-position=1234 \
  --stop-position=4567 \
  /var/lib/mysql/mysql-bin.000005 > before_incident.sql

# 第四步：跳过误操作行，手动编辑 SQL 后重放其余部分
# 方法一：导出到文件后用 sed/grep 过滤掉误操作的 DDL/DML
mysqlbinlog /var/lib/mysql/mysql-bin.000005 > all_events.sql
# 用编辑器打开 all_events.sql，定位到误操作的 BEGIN/COMMIT 区间并删除

# 方法二：精确用 position 范围分段重放
mysqlbinlog \
  --stop-position=4567 \
  /var/lib/mysql/mysql-bin.000005 | mysql -u root -p  # 重放到误操作前

mysqlbinlog \
  --start-position=5000 \
  /var/lib/mysql/mysql-bin.000005 | mysql -u root -p  # 从安全点继续重放

# MySQL 8.0+ GTID 模式（推荐，更简洁）
# 包含 uuid 下 1~100 的 GTID，排除第 101 个事务（即误操作的那个）
mysqlbinlog \
  --include-gtids='uuid:1-100' \
  --exclude-gtids='uuid:101' \
  mysql-bin.000005 | mysql -u root -p
```

> [!WARNING] PITR 的关键约束
> - **必须有完整的 binlog 链**：全量备份时的 binlog position 之后所有的 binlog 都不能丢
> - **`binlog_format` 必须是 ROW 或 MIXED**：STATEMENT 模式下 PITR 不可靠（相同的 SQL 在不同上下文中可能产生不同结果）
> - **GTID 需要 `gtid_executed` 一致**：使用 `--include-gtids` / `--exclude-gtids` 要求服务端启用了 `enforce_gtid_consistency=ON`
> - **恢复到某个时间点会覆盖该时间点之后的所有数据**：做好评估，建议先在测试库验证恢复流程

## 备份验证与自动化

> [!QUESTION] 思考：如果一周后发生灾难，你发现昨晚的备份根本打不开——那时候还来得及补救吗？
> **未经测试的备份等于没有备份**。定期验证是备份策略中最重要的环节。

### 验证方法

```bash
# mysqldump SQL 文件验证：在测试库导入一次
mysql -u root -p test_db < backup_latest.sql
# 检查关键表的数据量和行数是否符合预期

# XtraBackup 验证：prepare 阶段就是第一次验证
xtrabackup --prepare --target-dir=/data/backups/latest/
# prepare 成功 = 备份文件完整性合格
# 更进一步：恢复到从库或测试机做一次完整演练（至少每季度一次）
```

### 自动化方案

```bash
#!/bin/bash
# /opt/scripts/mysql-backup.sh — 每日备份脚本
set -euo pipefail

BACKUP_DIR="/data/backups"
DATE=$(date +%F)
RETENTION_DAYS=7

# 1. XtraBackup 全量备份
xtrabackup --backup \
  --target-dir="${BACKUP_DIR}/${DATE}/" \
  --user=backup_user --password=$(cat /etc/backup_pass) \
  --parallel=4

# 2. 压缩备份目录（节省磁盘空间）
tar czf "${BACKUP_DIR}/${DATE}.tar.gz" -C "${BACKUP_DIR}" "${DATE}"
rm -rf "${BACKUP_DIR}/${DATE}"

# 3. 清理超过保留期的旧备份
find "${BACKUP_DIR}" -name "*.tar.gz" -mtime +${RETENTION_DAYS} -delete

# 4. 备份元数据记录（方便追踪和恢复时定位）
echo "$(date +%F %T) | full | ${DATE} | OK" >> "${BACKUP_DIR}/backup.log"
```

```cron
# crontab -e — 每天凌晨 2 点执行
0 2 * * * /opt/scripts/mysql-backup.sh >> /var/log/mysql-backup-cron.log 2>&1
```

### 快速恢复清单

> [!CHECKLIST] PITR 快速恢复步骤
> 1. [ ] 确认误操作的准确时间
> 2. [ ] 找到最新可用的全量备份及其 binlog position
> 3. [ ] 停止应用写操作（防止二次损害）
> 4. [ ] 恢复全量备份到干净目录
> 5. [ ] 用 `--stop-datetime` 重放 binlog 到误操作前
> 6. [ ] 启动 MySQL 并验证关键表数据
> 7. [ ] 切换流量到新实例
> 8. [ ] 通知相关人员，更新 incident 记录

## 备份频率建议

| 数据类型 | 全量备份频率 | 增量备份频率 | binlog 留存 |
|---------|-----------|-----------|-----------|
| 核心交易数据 | 每天一次 | 每小时 | ≥ 7 天 |
| 用户数据 | 每天一次 | 每天 | ≥ 7 天 |
| 日志/归档数据 | 每周一次 | 按需 | 按需 |
| 测试环境 | 按需 | — | 按需 |

## 关联笔记

- [[hhs/MySQL/07-高可用与分布式/29-Binary Log]] — Binlog 是 PITR 的基础
- [[hhs/MySQL/07-高可用与分布式/30-主从复制详解]] — 从库可以作为只读备份节点
- [[hhs/DEV/Go-Database]] — Go 应用中处理数据库恢复错误的最佳实践