使用 BR 备份 TiDB 到 AWS S3 存储

前言

手里有几套 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）的集群执行快照备份恢复，将集群恢复到快照备份时的数据状态，同时恢复功能会依据集群副本设置恢复出多副本。

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

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

日志备份

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

日志备份的流程如下：

如何选择备份存储？

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 备份，则会报错：

bash 复制代码

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 版本，才能正常进行备份：

bash 复制代码

[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，所以只需要启动一次即可：

bash 复制代码

[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

启动日志备份任务：

bash 复制代码

[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

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

bash 复制代码

[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 备份目录：

备份文件已经生成。

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

bash 复制代码

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

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

快照备份脚本

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

bash 复制代码

[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

运行快照备份：

bash 复制代码

启动日志备份任务：
```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%

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

bash 复制代码

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

到这，TiDB 备份就完成了。

问题总结

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

网络限制

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

bash 复制代码

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

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

bash 复制代码

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

日志备份重复运行

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

bash 复制代码

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

快照备份中断

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

bash 复制代码

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 节点和备份存储系统有足够的网络带宽，备份存储系统能提供足够的写入和读取性能，否则，它们有可能成为备份恢复时的性能瓶颈。