博客 - TiDB BR (Backup & Restore) 生产级部署与运维指南

适用 TiDB 版本: v8.1.0+ (LTS) / v8.5.0+适用场景: 本地部署 / 私有云 (On-Premises) / 混合云参考来源: TiDB 官方文档 (docs.pingcap.com)

1. BR 概述

TiDB 备份与恢复工具 BR (Backup & Restore) 是 TiDB 分布式数据库原生的物理备份恢复命令行工具，用于对 TiDB 集群进行数据备份和恢复操作。

1.1 核心能力

能力	说明	生产建议
快照备份	备份某个物理时间点的全量数据（事务一致性快照）	每日执行（如凌晨 00:00）
日志备份	持续备份 KV 变更日志，实现低至 5 分钟 RPO	集群创建后立即启动，长期运行
快照恢复	将集群恢复到快照备份的时间点	用于全量恢复、跨环境克隆
PITR	Point-in-Time Recovery，恢复到任意历史时间点	用于误操作回滚、数据审计
库表级过滤	支持备份/恢复指定数据库或表	用于核心业务局部备份/恢复
备份加密	支持 AES 加密备份数据	敏感数据场景必须启用
断点恢复	支持恢复失败后的断点续传	大规模恢复时降低风险

1.2 备份方案推荐（生产黄金标准）

┌─────────────────────────────────────────────────────────────┐
│                    推荐生产备份架构                            │
├─────────────────────────────────────────────────────────────┤
│  日志备份 (log backup) ──────→ 持续运行，低 RPO (~5min)     │
│         ↓                                                   │
│  快照备份 (snapshot) ─────────→ 每日执行，用于全量基线       │
│         ↓                                                   │
│  备份存储 (S3/MinIO/NFS) ─────→ 统一存储，异地灾备          │
│         ↓                                                   │
│  保留策略管理 ─────────────────→ 自动清理过期数据            │
└─────────────────────────────────────────────────────────────┘

方案说明：

日志备份提供实时保护，RPO 低至 5 分钟；
快照备份提供周期性全量基线，降低恢复时间；
两者配合使用，可实现 PITR（任意时间点恢复）。

2. 安装部署

2.1 安装方式（推荐 TiUP）

# 方式一：在线安装 BR（推荐，与 TiDB 集群版本一致）
tiup install br

# 方式二：安装指定版本（确保与 TiDB 集群大版本一致）
tiup install br:v8.1.0

# 验证安装
tiup br --version

重要兼容性提示：强烈建议使用与 TiDB 集群相同大版本的 BR 工具。跨大版本备份恢复可能导致系统表不兼容。从 v7.5.0 起，版本兼容性检查更加严格。

2.2 推荐部署节点

组件	推荐配置	说明
BR 运行节点	8 核 CPU / 16 GB 内存 / 高性能 SSD	备份操作对资源消耗较大
TiKV 节点	额外预留 2 CPU core + 高性能磁盘	备份时会占用 TiKV 资源
网络带宽	备份速度需求（建议万兆网络）	大规模集群的瓶颈常在网络

2.3 安装后检查

# 检查 BR 是否能访问 PD
tiup br --pd "${PD_IP}:2379" debug backupmeta --storage "local:///tmp/br_test" 2>/dev/null || echo "检查 PD 连接"

# 确认 TiUP 环境变量
echo $PATH | grep tiup
which tiup

3. 环境要求与前置检查清单

3.1 生产环境检查清单（必须逐项确认）

检查项	检查命令/方法	通过标准
TiDB 集群状态正常	`tiup cluster display <cluster-name>`	所有节点 Up
PD 可达	`curl http://{PD_IP}:2379/pd/api/v1/health`	返回 healthy
TiKV 磁盘空间充足	`tiup cluster exec <cluster-name> -N tikv --command "df -h"`	使用率 < 80%
备份存储可写入	详见第 4 节	成功写入测试文件
网络带宽充足	`iperf3` 或 `scp` 测速	带宽 > 备份吞吐需求
GC 时间合理	`SELECT * FROM mysql.tidb WHERE variable_name='tikv_gc_life_time';`	默认 10m0s，备份期间自动保护
集群版本与 BR 版本一致	`tiup br --version` vs `SELECT tidb_version();`	大版本一致
无正在运行的备份任务	`tiup br log status` / `ps aux \| grep br`	无冲突任务
系统时间同步	`timedatectl status` / `ntpq -p`	NTP 已同步
备份目录权限正确	`ls -ld /backup` / `mc ls minio/backup`	BR 有读写权限

3.2 集群关键配置检查

# 检查 GC 配置（BR 备份会自动保护 GC SafePoint，无需手动调整）
mysql -u root -p -e "SELECT VARIABLE_NAME, VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME LIKE '%%gc%%';"

# 检查 TiKV 备份线程数（影响备份速度和对集群的影响）
tiup cluster exec tidb-test -N tikv --command   "cat /path/to/tikv.toml | grep -A2 'backup'"

# 推荐配置（tikv.toml）
# [backup]
# num-threads = 4          # 默认，根据集群负载调整
# batch-size = 8           # 默认

4. 备份存储系统配置

TiDB BR 支持以下存储后端：

Amazon S3 / 兼容 S3 的存储（MinIO、Ceph、阿里云 OSS、腾讯云 COS）
Google Cloud Storage (GCS)
Azure Blob Storage
NFS（POSIX 文件系统）

生产推荐：优先使用 S3 兼容对象存储（如 MinIO、阿里云 OSS），其次是挂载 NFS。不推荐将备份数据直接存储到本地磁盘（数据分散在各 TiKV 节点，难以管理和恢复）。

4.1 S3 / 兼容 S3 存储配置（MinIO、阿里云 OSS）

4.1.1 IAM 方式（推荐，最安全）

为运行 TiKV 和 BR 的节点关联 IAM Role，无需在命令行中传递密钥。

# 备份命令（IAM 方式）
tiup br backup full     --pd "${PD_IP}:2379"     --storage "s3://backup-bucket/tidb-cluster1/snapshot-${DATE}?region=cn-hangzhou"     --send-credentials-to-tikv=false     --s3.region "cn-hangzhou"     --log-file backupfull.log

4.1.2 Access Key 方式

# 阿里云 OSS 示例
export S3_ENDPOINT="http://oss-cn-hangzhou.aliyuncs.com"
export AWS_ACCESS_KEY_ID="<your-access-key>"
export AWS_SECRET_ACCESS_KEY="<your-secret-key>"

# 备份命令（带密钥）
tiup br backup full     --pd "${PD_IP}:2379"     --storage "s3://backup-bucket/tidb-cluster1/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY_ID}&secret-access-key=${AWS_SECRET_ACCESS_KEY}&endpoint=${S3_ENDPOINT}"     --s3.region "cn-hangzhou"     --send-credentials-to-tikv=true     --log-file backupfull.log

4.1.3 MinIO 配置示例

export MINIO_ENDPOINT="http://minio.example.com:9000"
export MINIO_ACCESS_KEY="minioadmin"
export MINIO_SECRET_KEY="minioadmin"

# 备份到 MinIO
tiup br backup full     --pd "${PD_IP}:2379"     --storage "s3://tidb-backup/cluster1/snapshot-${DATE}?access-key=${MINIO_ACCESS_KEY}&secret-access-key=${MINIO_SECRET_KEY}&endpoint=${MINIO_ENDPOINT}&force-path-style=true"     --s3.region "us-east-1"     --send-credentials-to-tikv=true     --log-file backupfull.log

注意：使用 MinIO 等私有 S3 兼容存储时，必须添加 force-path-style=true 参数。

4.2 NFS 配置

# 1. 在所有 TiKV 节点和 BR 节点挂载 NFS
sudo mount -t nfs nas.example.com:/backup/nfs /backup/nfs

# 2. 确保挂载一致性（推荐写入 /etc/fstab）
echo "nas.example.com:/backup/nfs /backup/nfs nfs defaults,noatime,nolock 0 0" | sudo tee -a /etc/fstab

# 3. 备份命令
tiup br backup full     --pd "${PD_IP}:2379"     --storage "local:///backup/nfs/tidb-cluster1/snapshot-${DATE}"     --log-file backupfull.log

⚠️ NFS 警告：如果没有将 NFS 挂载到所有 TiKV 节点和 BR 节点，备份数据会分散在本地磁盘，导致恢复时 SST file not found 错误。

4.3 存储目录组织规范（生产标准）

backup-tidb-cluster1/                          # 统一备份根目录
├── logbackup/                                 # 日志备份目录（长期运行）
│   ├── 20260701/
│   ├── 20260702/
│   └── ...
├── snapshot-20260701000000/                  # 快照备份（按日期命名）
├── snapshot-20260702000000/
├── snapshot-20260703000000/
└── ...

5. 快照备份（全量备份）操作

5.1 全集群快照备份

# 设置环境变量
export PD_IP="10.0.1.10"
export BACKUP_BUCKET="s3://backup-bucket/tidb-cluster1"
export DATE=$(date +%Y%m%d%H%M%S)

# 执行全量备份
tiup br backup full     --pd "${PD_IP}:2379"     --storage "${BACKUP_BUCKET}/snapshot-${DATE}"     --compression zstd     --compression-level 3     --ignore-stats=false     --log-file "backupfull-${DATE}.log"

参数说明： | 参数 | 说明 | 默认值 | 建议 | |------|------|--------|------| | --backupts | 指定备份时间点（TSO 或时间戳） | 当前时间 | 一般不需要指定 | | --compression | 压缩算法：lz4/snappy/zstd | zstd | 保持默认 zstd | | --compression-level | 压缩级别 | 3 | 保持默认 | | --ignore-stats | 是否忽略统计信息 | true (v8.5.0+) | 生产建议设为 false | | --ratelimit | 每个 TiKV 限速（MiB/s） | 无限制 | 高峰时段建议限制 | | --checksum | 备份完成后校验 | false (v8.5.0+) | 大数据量时可关闭 |

5.2 备份单个数据库

tiup br backup db     --pd "${PD_IP}:2379"     --db "mydb"     --storage "${BACKUP_BUCKET}/snapshot-mydb-${DATE}"     --log-file "backup-mydb-${DATE}.log"

5.3 备份单张表

tiup br backup table     --pd "${PD_IP}:2379"     --db "mydb"     --table "orders"     --storage "${BACKUP_BUCKET}/snapshot-orders-${DATE}"     --log-file "backup-orders-${DATE}.log"

5.4 使用过滤规则备份多张表

tiup br backup full     --pd "${PD_IP}:2379"     --filter 'db1.*'     --filter 'db2.tbl_*'     --filter '!db3.*'     --storage "${BACKUP_BUCKET}/snapshot-filtered-${DATE}"     --log-file "backup-filtered-${DATE}.log"

5.5 加密备份（生产敏感数据场景）

# 生成 128-bit 密钥（16 字节十六进制）
export BACKUP_KEY=$(openssl rand -hex 16)

# 加密备份（务必保存密钥！）
tiup br backup full     --pd "${PD_IP}:2379"     --storage "${BACKUP_BUCKET}/snapshot-encrypted-${DATE}"     --crypter.method aes128-ctr     --crypter.key "${BACKUP_KEY}"     --log-file "backup-encrypted-${DATE}.log"

# 将密钥保存到安全位置（KMS/保险库）
echo "Backup Key: ${BACKUP_KEY}" | tee backup-key-${DATE}.secret
chmod 600 backup-key-${DATE}.secret

⚠️ 密钥安全警告：密钥丢失则备份数据永久不可恢复。生产环境必须使用 KMS 或密钥管理系统保存密钥。

5.6 备份性能与影响

备份速度：单 TiKV 50 MB/s ~ 100 MB/s，可扩展；
对集群影响：CPU 充裕时可控制在 20% 以下；资源紧张时可通过 tikv.backup.num-threads 和 --ratelimit 降低影响；
最佳实践：在业务低峰期（如凌晨）执行全量备份。

6. 日志备份（增量/PITR）操作

日志备份是持续运行的任务，在所有 TiKV 节点上备份 KV 变更日志，是实现 PITR 的基础。

6.1 启动日志备份

export PD_IP="10.0.1.10"
export LOG_BACKUP_STORAGE="s3://backup-bucket/tidb-cluster1/logbackup"

tiup br log start     --task-name=pitr     --pd="${PD_IP}:2379"     --storage="${LOG_BACKUP_STORAGE}"

启动时机：日志备份应在集群投入使用前或最迟投入使用后立即启动。如果已有快照备份，建议设置 --start-ts 为最近快照备份的 BackupTS，确保日志连续性。

6.2 查询日志备份状态

tiup br log status --task-name=pitr --pd="${PD_IP}:2379"

输出解读：

● Total 1 Tasks.
> #1 <
              name: pitr
            status: ● NORMAL               # NORMAL / ERROR / PAUSE
             start: 2026-07-01 20:08:03
               end: 2090-11-18 22:07:45
           storage: s3://backup-bucket/tidb-cluster1/logbackup
       speed(est.): 0.82 ops/s
checkpoint[global]: 2026-07-02 14:52:15; gap=2m52s   # 全局检查点，可恢复的最晚时间点

6.3 暂停与恢复日志备份

# 暂停（如集群维护期间）
tiup br log pause --task-name=pitr --pd="${PD_IP}:2379"

# 恢复
tiup br log resume --task-name=pitr --pd="${PD_IP}:2379"

# ⚠️ 注意：暂停超过 24 小时（GC 默认周期），日志数据可能被 GC 回收，导致无法恢复！

6.4 停止日志备份（谨慎操作）

# 停止日志备份（删除任务元信息，数据保留）
tiup br log stop --task-name=pitr --pd="${PD_IP}:2379"

# 停止后可在相同 storage 路径重新启动（自动续传）
# 或在新的 storage 路径创建新任务

6.5 查看日志备份元信息

# 查询最早和最晚的可恢复时间点
tiup br log metadata --storage="${LOG_BACKUP_STORAGE}"

# 输出示例：
# [log-min-date="2026-07-01 20:08:03"]
# [log-max-date="2026-07-02 15:00:15"]

6.6 日志备份加密（v8.4.0+）

export LOG_KEY=$(openssl rand -hex 16)

tiup br log start     --task-name=pitr-encrypted     --pd="${PD_IP}:2379"     --storage="${LOG_BACKUP_STORAGE}"     --log.crypter.method aes128-ctr     --log.crypter.key "${LOG_KEY}"

6.7 日志备份对集群的影响

资源占用约 5%（单独运行时）；
每隔 3~5 分钟将变更日志刷新到备份存储；
自动请求 PD 阻止未备份数据被 GC。

7. 恢复操作

7.1 快照恢复（全量恢复）

7.1.1 恢复到全新空集群

export PD_IP="10.0.1.20"        # 目标集群 PD
export BACKUP_PATH="s3://backup-bucket/tidb-cluster1/snapshot-20260701000000"

tiup br restore full     --pd "${PD_IP}:2379"     --with-sys-table     --fast-load-sys-tables     --storage "${BACKUP_PATH}"     --ratelimit 128     --log-file restorefull.log

参数说明： | 参数 | 说明 | 建议 | |------|------|------| | --with-sys-table | 恢复部分系统表（账号、权限、SQL Binding 等） | 必须，恢复集群权限 | | --fast-load-sys-tables | 物理方式恢复系统表（v8.5.5+） | 新集群推荐开启 | | --ratelimit | 每个 TiKV 恢复限速（MiB/s） | 根据目标集群负载调整 | | --load-stats | 恢复统计信息（v8.0.0+ 默认开启） | 保持默认 |

⚠️ 重要：恢复数据时，BR 会尽可能多地占用目标集群资源。强烈建议恢复到新集群或离线集群，避免恢复正在提供服务的生产集群。

7.1.2 恢复指定数据库

tiup br restore db     --pd "${PD_IP}:2379"     --db "mydb"     --ratelimit 128     --storage "${BACKUP_PATH}"     --log-file restore_db.log

注意：只能恢复到同名数据库。

7.1.3 恢复指定表

tiup br restore table     --pd "${PD_IP}:2379"     --db "mydb"     --table "orders"     --ratelimit 128     --storage "${BACKUP_PATH}"     --log-file restore_table.log

7.1.4 恢复加密备份

# 恢复时传入相同的加密参数
tiup br restore full     --pd "${PD_IP}:2379"     --with-sys-table     --storage "${BACKUP_PATH}"     --crypter.method aes128-ctr     --crypter.key "0123456789abcdef0123456789abcdef"     --log-file restore_encrypted.log

7.2 PITR 恢复（恢复到任意时间点）

PITR 需要：

日志备份数据（--storage）
恢复时间点之前最近的快照备份（--full-backup-storage）
目标集群为全新空集群

export PD_IP="10.0.1.20"
export LOG_STORAGE="s3://backup-bucket/tidb-cluster1/logbackup"
export FULL_BACKUP="s3://backup-bucket/tidb-cluster1/snapshot-20260701000000"
export RESTORE_TIME="2026-07-02 14:30:00+0800"

# PITR 恢复
tiup br restore point     --pd="${PD_IP}:2379"     --storage="${LOG_STORAGE}"     --full-backup-storage="${FULL_BACKUP}"     --restored-ts "${RESTORE_TIME}"     --pitr-concurrency 64     --log-file restore_pitr.log

参数说明： | 参数 | 说明 | 建议 | |------|------|------| | --restored-ts | 恢复到的时间点（TSO 或时间戳） | 精确到秒 | | --start-ts | 日志恢复起始时间点 | 一般不需要指定 | | --pitr-concurrency | 日志恢复并发数 | 默认 16，可根据集群调整 | | --pitr-batch-size | 日志恢复批次大小（字节） | 默认 16 MiB | | --pitr-batch-count | 日志恢复批次文件数 | 默认 8 |

PITR 限制：

仅支持恢复到全新空集群；

恢复期间不能同时运行日志备份任务；

不支持恢复系统表中的用户表和权限表（需单独处理）；

多次恢复必须保证时间连续性，不可跳跃。

7.3 使用过滤器恢复（v8.5.5+）

# 仅恢复 db1 和 db2 的数据
tiup br restore point     --pd="${PD_IP}:2379"     --storage="${LOG_STORAGE}"     --full-backup-storage="${FULL_BACKUP}"     --restored-ts "${RESTORE_TIME}"     --filter 'db1.*' --filter 'db2.*'     --log-file restore_pitr_filtered.log

注意：过滤器必须作用于不同的数据库或不重叠的表集合，且目标集群中不能存在同名的库表。

7.4 恢复性能指标

恢复类型	性能指标	说明
快照恢复	单 TiKV ~1 GiB/s	速度可扩展
日志恢复	30 GiB/h	单 TiKV 速度
PITR 全量	2 TiB/h（全量阶段）	取决于集群规模

7.5 断点恢复（恢复失败后的续传）

从 v8.5.5 开始，BR 默认将断点数据存储在下游集群中。恢复失败后可重新执行相同命令，自动跳过已恢复部分。

如果需要指定外部断点存储：

tiup br restore full     --pd "${PD_IP}:2379"     --storage "${BACKUP_PATH}"     --checkpoint-storage "s3://temp-bucket/checkpoints"     --log-file restore_checkpoint.log

8. 备份数据生命周期管理

8.1 保留策略设计

假设保留策略为 7 天（备份保留期）：

当前时间: 2026-07-08
需要保留的快照: 2026-07-02, 07-03, 07-04, 07-05, 07-06, 07-07, 07-08
需要保留的日志: 从 2026-07-02 开始的所有日志

8.2 清理过期日志备份

# 只清理全量快照之前的日志（保留快照之间的日志，用于 PITR）
# 例如：只保留 2026-07-02 00:00 之后的日志
tiup br log truncate     --until '2026-07-02 00:00:00+0800'     --storage "${LOG_BACKUP_STORAGE}"     --yes

# 干运行（不实际删除，先确认影响范围）
tiup br log truncate     --until '2026-07-02 00:00:00+0800'     --storage "${LOG_BACKUP_STORAGE}"     --dry-run

清理原则：

进行 PITR 需要恢复时间点之前的全量备份 + 全量备份到恢复时间点之间的日志；

建议只清理全量快照之前的日志备份；

对于超过保留期的全量备份，直接删除或归档目录。

8.3 清理过期快照备份

# 直接删除 S3 中的过期快照目录
aws s3 rm --recursive s3://backup-bucket/tidb-cluster1/snapshot-20260625000000/

# 或使用 MinIO mc 命令
mc rm --recursive --force minio/tidb-backup/cluster1/snapshot-20260625000000/

# 或使用 rclone
rclone delete remote:backup-bucket/tidb-cluster1/snapshot-20260625000000/

9. 生产环境关键注意事项

9.1 使用限制（红线）

限制	说明	风险
不能同时运行多个备份任务	不支持并行快照备份	任务失败、集群异常
PITR 仅支持恢复到全新空集群	目标集群必须为空	数据冲突、恢复失败
恢复期间不支持日志备份	PITR 恢复时暂停日志备份	恢复数据异常
恢复期间不支持 TiCDC	BR 恢复与 TiCDC 冲突	下游数据不一致
不建议备份正在恢复的表	备份数据可能异常	备份数据损坏
跨大版本不兼容	v7.5.0+ 兼容性严格	系统表恢复失败

9.2 版本兼容性矩阵（LTS 版本）

备份集群	兼容恢复目标	不兼容目标
v7.5.0	v7.5.0+	-
v8.1.0	v8.1.0+	-
v8.5.0	v8.5.0+	-

若仅备份非系统表的业务数据，所有版本之间均兼容。恢复 mysql 系统表时，可能出现不兼容。可通过 --with-sys-table=false 跳过系统表恢复。

9.3 与 TiCDC 的关系

BR 恢复的数据无法被同步到下游：BR 直接导入 SST 文件，下游无法获得上游 SST 文件；
v8.2.0+：如果恢复目标集群有 CheckpointTS 早于 BackupTS 的 Changefeed，BR 会拒绝恢复；
建议：恢复完成后，重新创建 TiCDC Changefeed。

9.4 备份最佳实践

定时备份：使用 cron 定时执行快照备份（如每天 00:00）；
监控报警：监控日志备份的 checkpoint gap，超过 10 分钟应报警；
定期演练：每季度执行一次恢复演练，验证备份数据可用性；
异地灾备：备份数据应复制到异地存储；
密钥管理：加密备份的密钥必须使用 KMS 管理，禁止明文存储；
日志审计：保留所有 BR 操作日志，便于问题排查。

10. 常见问题与排障

Q1: 备份日志中出现 `key locked Error`

现象：backup occur kv error: locked

处理：BR 会尝试自动清锁。少量报错不影响备份正确性。如频繁出现，检查集群是否存在长时间未提交的事务。

Q2: 备份失败报错 `SST file not found`

现象：恢复时找不到 SST 文件

原因：使用 local storage 时，备份数据分散在各个 TiKV 节点本地磁盘，未聚合到统一存储。

解决：

使用 S3/NFS 等共享存储；
或手动将所有 TiKV 节点的备份文件聚合到同一目录。

Q3: 备份对集群影响过大

处理：

# 方案 1：降低 TiKV 备份线程数
tiup cluster edit-config <cluster-name>
# [backup]
# num-threads = 2

# 方案 2：BR 命令限速
tiup br backup full --ratelimit 64 ...

# 方案 3：开启 BR 自动调节（v5.4.0+，默认开启）
# 高负载时自动限制备份速度

Q4: 恢复后系统表报错 `incompatible system table`

原因：跨版本恢复系统表结构不兼容。

处理：

# 跳过系统表恢复，仅恢复业务数据
tiup br restore full --with-sys-table=false ...

# 恢复后手动重建用户和权限

Q5: PITR 恢复失败 `ErrBackupGCSafepointExceeded`

原因：日志备份任务停止后，GC 已清理了相关数据。

处理：无法恢复，只能配置新的日志备份路径重新创建任务。停止日志备份任务时务必谨慎。

Q6: 如何验证备份数据完整性？

# 离线校验备份数据
tiup br debug checksum --storage "${BACKUP_PATH}"

文档维护：本指南基于 TiDB 官方文档，随 TiDB 版本迭代需定期更新。建议在每次 TiDB 大版本升级后重新验证本指南中的命令和参数。

TiDB BR (Backup & Restore) 生产级部署与运维指南

目录