目录

前言

手里有几套 TiDB 集群数据库没有备份，一直在裸奔，几个备份厂商（爱数，NBU，Veeam）也都不支持备份 TiDB，正好这两天有空研究了一下官方文档，发现官方自带的 BR 工具看着很强大，所以测试了一下。

TiDB 备份与恢复概述：https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-overview/

本文记录一下使用 BR 将 TiDB 数据库备份到 AWS S3 存储的过程，仅供参考。

BR 工具

基于 Raft 协议和合理的部署拓扑规划，TiDB 实现了集群的高可用，当集群中少数节点挂掉时，集群依然能对外提供服务。在此基础上，为了更进一步保证用户数据的安全，TiDB 还提供了集群的备份与恢复 (Backup & Restore, BR) 功能，作为数据安全的最后一道防线，使得集群能够免于严重的自然灾害，提供业务误操作“复原”的能力。

如何备份数据？

TiDB 支持两种类型的备份，应该使用哪种备份？ 全量备份包含集群某个时间点的全量数据，日志备份包含业务写入在 TiDB 产生的数据变更记录。推荐这两种备份方式一起使用：

  • 开启日志备份：运行 br log start 命令来启动日志备份任务，任务会在每个 TiKV 节点上持续运行，以小批量的形式定期将 TiDB 变更数据备份到指定存储中。
  • 定期执行快照（全量）备份：运行 br backup full 命令来备份集群快照到备份存储，例如在每天零点进行集群快照备份。

快照备份

快照备份是集群全量备份的一种实现。它基于 TiDB 的多版本并发控制 (MVCC) 实现，将指定快照包含的所有数据备份到目标存储中。备份下来的数据大小约等于集群（压缩后的）单副本数据大小。备份完成之后，你可以在一个空集群或不存在数据冲突（相同 schema 或 table）的集群执行快照备份恢复，将集群恢复到快照备份时的数据状态，同时恢复功能会依据集群副本设置恢复出多副本。

快照数据备份和恢复的架构如下：

使用 BR 备份 TiDB 到 AWS S3 存储

集群快照数据备份的流程如下：

使用 BR 备份 TiDB 到 AWS S3 存储 - 图2

日志备份

日志备份和 PITR 的架构如下：

使用 BR 备份 TiDB 到 AWS S3 存储 - 图3

日志备份的流程如下：

使用 BR 备份 TiDB 到 AWS S3 存储 - 图4

如何选择备份存储？

Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是推荐的存储系统选择，使用这些系统，你无需担心备份容量、备份带宽规划等。

如果 TiDB 集群部署在自建机房中，则推荐以下方式：

  • 搭建 MinIO 作为备份存储系统，使用 S3 协议将数据备份到 MinIO 中。
  • 挂载 NFS（如 NAS）盘到 br 工具和所有的 TiKV 实例，使用 POSIX file system 接口将备份数据写入对应的 NFS 目录中。

以上都是一些基本概念，主要了解一下 BR 工具以及备份的流程和逻辑，更多内容可以参考我整理的 TiDB 备份文章：TiDB 备份与恢复整理。

BR 安装配置

使用备份恢复功能的部署要求如下：

  • BR、TiKV 节点和备份存储系统需要提供大于备份速度的的网络带宽。当集群特别大的时候，备份和恢复速度上限受限于备份网络的带宽。
  • 备份存储系统还需要提供足够的写入/读取性能 (IOPS)，否则它有可能成为备份恢复时的性能瓶颈。
  • TiKV 节点需要为备份准备至少额外的两个 CPU core 和高性能的磁盘，否则备份将对集群上运行的业务产生影响。
  • 推荐 br 工具运行在 8 核+/16 GB+ 的节点上。

官方文档中 BR 的安装比较简单，可以直接使用 TiUP 在线安装：tiup install br，但是这种情况下安装出来的 br 版本跟 tiup 版本是一致的。

也就是说，我的环境 tiup 版本是 v8.5.3，安装的 BR 版本就是 v8.5.3，但是我的 TiDB 集群版本是 v7.5.0，此时如果用这个版本的 BR 备份，则会报错：

1
Error: running BR in incompatible version of cluster, if you believe it's OK, use --check-requirements=false to skip.: TiKV node ******:20160 version 7.5.0 is too old because the PITR id map is written into the cluster system table mysql.tidb_pitr_id_map, please use the tikv with version v8.4.0+: [BR:Common:ErrVersionMismatch]version mismatch

这种情况下就需要手动安装与集群版本一致的 BR 版本，才能正常进行备份：

1
2
3
4
[root@tidb ~]# wget https://tiup-mirrors.pingcap.com/br-v7.5.0-linux-amd64.tar.gz
[root@tidb ~]# tar -xf br-v7.5.0-linux-amd64.tar.gz -C /usr/sbin/
[root@tidb ~]# br --version
Release Version: v7.5.0

至此，BR 工具部署完成，只需要在执行的这台上安装即可。

BR 备份部署

本文分享两个脚本，分别备份 TiDB 的集群快照以及日志，在网上以及 TiDB 社区找了很久没有找到相关的脚本，还是咨询原厂得到的。

本文使用的是 AWS S3 存储进行备份，阿里云 S3 也可以，或者自己本地搭建的 MinIO 也可以，大家根据实际情况自行选择即可。

日志备份脚本

日志备份是一个 task，所以只需要启动一次即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@tidb ~]# cat<<-EOF>/root/scripts/brbackuplog.sh
AccessKey="根据实际情况填写"
SecretKey="根据实际情况填写"
Bucket="根据实际情况填写"
Endpoint="根据实际情况填写"
PDIP="根据实际情况填写"
export AWS_ACCESS_KEY_ID=$AccessKey
export AWS_SECRET_ACCESS_KEY=$SecretKey
CURDATE=$(date +%Y%m%d%H%M%S)
br log start --task-name=pitr \
--pd "${PDIP}" \
--storage "s3://${Bucket}/backup-data/log-backup" \
--s3.endpoint="https://${Endpoint}" \
--s3.provider="aws" \
--log-file brbackuplog-$CURDATE.log

echo s3://${Bucket}/backup-data/log-backup
EOF

启动日志备份任务：

1
2
3
4
5
6
[root@tidb ~]# chmod +x /root/scripts/brbackuplog.sh
[root@tidb ~]# sh /root/scripts/brbackuplog.sh
Detail BR log in brbackuplog-20251104104110.log 
[2025/11/04 10:41:56.346 +08:00] [INFO] [collector.go:77] ["log start"] [streamTaskInfo="{taskName=pitr,startTs=461956478452891654,endTS=999999999999999999,tableFilter=*.*}"] [pausing=false] [rangeCount=2]
[2025/11/04 10:41:57.909 +08:00] [INFO] [collector.go:77] ["log start success summary"] [total-ranges=0] [ranges-succeed=0] [ranges-failed=0] [backup-checksum=143.034815ms] [total-take=47.704461672s]
s3://*******/backup-data/log-backup

启动后，可以检查任务状态：

1
2
3
4
5
6
7
8
9
10
11
[root@tidb ~]# br log status --task-name=pitr --pd="根据实际情况填写"
Detail BR log in /tmp/br.log.2025-11-04T10.42.21+0800 
● Total 1 Tasks.
> #1 <
              name: pitr
            status: ● NORMAL
             start: 2025-11-04 10:41:55.192 +0800
               end: 2090-11-18 22:07:45.624 +0800
           storage: s3://*******/backup-data/log-backup
       speed(est.): 444.08 ops/s
checkpoint[global]: 2025-11-04 10:41:55.192 +0800; gap=28s

可以看到状态是 NORMAL，代表任务正常，日志备份在正常运行，查看 AWS S3 备份目录：

使用 BR 备份 TiDB 到 AWS S3 存储 - 图5

备份文件已经生成。

再分享几个运维日志备份任务的命令：

1
2
3
4
5
6
br log pause：暂停备份任务
br log resume：恢复备份任务
br log status：检查备份任务
br log stop：停止备份任务，并删除任务元信息
br log start：启动备份任务
br log truncate：从备份存储中清理日志备份数据

如果日志备份任务出现问题，可以使用以上命令进行管理。

快照备份脚本

快照备份就是全备了，可以写成一个计划任务，每隔一段时间进行备份一次：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@tidb ~]# cat<<-EOF>/root/scripts/brbackupfull.sh 
AccessKey="根据实际情况填写"
SecretKey="根据实际情况填写"
Bucket="根据实际情况填写"
Endpoint="根据实际情况填写"
PDIP="根据实际情况填写"
export AWS_ACCESS_KEY_ID=$AccessKey
export AWS_SECRET_ACCESS_KEY=$SecretKey
CURDATE=$(date +%Y%m%d%H%M%S)
br backup full --pd "${PDIP}" \
--storage "s3://${Bucket}/backup-data/snapshot-${CURDATE}" \
--s3.endpoint="https://${Endpoint}" \
--s3.provider="aws" \
--ratelimit 16 \
--log-file brbackupfull-$CURDATE.log

echo s3://${Bucket}/backup-data/snapshot-${CURDATE}
EOF

运行快照备份：

1
2
3
4
5
6
7
启动日志备份任务：
```bash
[root@tidb ~]# chmod +x /root/scripts/brbackupfull.sh
[root@tidb ~]# sh /root/scripts/brbackupfull.sh
Detail BR log in brbackupfull-20251104130417.log 
[2025/11/04 13:04:17.305 +08:00] [WARN] [backup.go:312] ["setting `--ratelimit` and `--concurrency` at the same time, ignoring `--concurrency`: `--ratelimit` forces sequential (i.e. concurrency = 1) backup"] [ratelimit=16.78MB/s] [concurrency-specified=4]
Full Backup <-\......................................................................................................................................................................................> 0.76%

写入计划任务，每周执行一次：

1
2
crontab -e
00 00 * * 0 /home/oracle/scripts/brbackupfull.sh

到这，TiDB 备份就完成了。

问题总结

在 BR 备份部署过程中，还是遇到了一些问题的，这里大概记录一下。

网络限制

由于网络限制，不管是阿里云还是 AWS 的 Endpoint，都可以开放给 TiDB 执行备份的主机进行访问，否则无法备份：

1
2
Error: failed to get region of bucket ******: RequestError: send request failed
caused by: dial tcp 54.231.195.232:443: i/o timeout

S3 权限

备份集群的 TiKV 和 br 命令行工具需要的 s3://******/backup-data 权限：

  • s3:ListBucket
  • s3:GetObject
  • s3:DeleteObject
  • s3:PutObject
  • s3:AbortMultipartUpload

如果不授权，备份时候会报错：

1
2
Error: Forbidden: Forbidden
        status code: 403, request id: ******, host id: ********

日志备份重复运行

日志备份任务开启后会一直运行，不需要再次启动一个，否则报错：

1
Error: It supports single stream log task currently: [BR:Stream:ErrStreamLogTaskExist]stream task already exists

快照备份中断

快照备份执行过程中中断，日志报错：

1
Error: error happen in store 1 at *********: Io(Custom { kind: Other, error: "failed to put object rusoto error timeout after 15mins for upload part in s3 storage" }): [BR:KV:ErrKVStorage]tikv storage occur I/O error

这个报错一般是链路上有瓶颈，可以限制备份速度，调整参数 --ratelimit。

写在最后

快照备份推荐在业务低峰时执行集群快照数据备份，这样能最大程度地减少对业务的影响。BR 恢复数据时会尽可能多地占用恢复集群的资源，因此推荐恢复数据到新集群或离线集群。应避免恢复数据到正在提供服务的生产集群，否则，恢复期间会对业务产生不可避免的影响。

推荐使用支持 Amazon S3、GCS 或 Azure Blob Storage 协议的存储系统保存备份数据；应确保 BR、TiKV 节点和备份存储系统有足够的网络带宽，备份存储系统能提供足够的写入和读取性能，否则，它们有可能成为备份恢复时的性能瓶颈。