TiDB 备份与恢复：BR 工具的深入应用与实战解析

一、TiDB 备份恢复工具 BR 简介

BR 全称为 Backup & Restore, 是TiDB分布式备份恢复的命令行工具, 用于对TiDB集群进行数据备份和恢复。

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

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

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

TiDB BR 备份的恢复：

• 如果你只有全量备份数据，或者想恢复某个确定的全量备份，那么可以使用 br restore 恢复指定的全量备份。
• 如果你按照以上推荐的的方式进行备份，那么你可以使用 br restore point 恢复到备份保留期内任意时间点。

二、备份恢复工具 BR 整体架构

快照（全量）数据备份和恢复的架构：

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

完整的备份交互流程描述如下：

1.BR 接收备份命令 br backup full。

• 获得备份快照点 (backup ts) 和备份存储地址。

2.BR 调度备份数据。

• Pause GC：配置 TiDB GC，防止要备份的数据被 TiDB GC 机制回收。
• Fetch TiKV and Region info：访问 PD，获取所有 TiKV 节点访问地址以及数据的 Region 分布信息。
• Request TiKV to back up data：创建备份请求，发送给 TiKV 节点，备份请求包含 backup ts、需要备份的 region、备份存储地址。

3.TiKV 接受备份请求，初始化 backup worker。

4.TiKV 备份数据。

• Scan KVs：backup worker 从 Region (only leader) 读取 backup ts 对应的数据。
• Generate SST：backup worker 将读取到的数据保存到 SST 文件，存储在内存中。
• Upload SST：backup worker 上传 SST 文件到备份存储中。

5.BR 从各个 TiKV 获取备份结果。

• 如果局部数据因为 Region 变动而备份失败，比如 TiKV 节点故障，BR 将重试这些数据的备份。
• 如果任意数据被判断为不可重试的备份失败，则备份任务失败。
• 全部数据备份成功后，则在最后完成元信息备份。

6.BR 备份元信息。

• Back up schemas：备份 table schema，同时计算 table data checksum。
• Upload metadata：生成 backup metadata，并上传到备份存储。backup metadata 包含 backup ts、表和对应的备份文件、data checksum 和 file checksum 等信息。

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

完整的恢复交互流程描述如下：

1.BR 接收恢复命令 br restore。

• 获得快照备份数据存储地址、要恢复的 database 或 table。
• 检查要恢复的 table 是否存在及是否符合要求。

2.BR 调度恢复数据。

• Pause Region schedule：请求 PD 在恢复期间关闭自动 Region schedule。
• Restore schema：读取备份数据的 schema、恢复的 database 和 table（注意新建表的 table ID 与备份数据可能不一样）。
• Split & scatter Region：BR 基于备份数据信息，请求 PD 分配 Region (split Region)，并调度 Region 均匀分布到存储节点上 (scatter Region)。每个 Region 都有明确的数据范围 [start key, end key)。
• Request TiKV to restore data：根据 PD 分配的 Region 结果，发送恢复请求到对应的 TiKV 节点，恢复请求包含要恢复的备份数据及 rewrite 规则。

3.TiKV 接受恢复请求，初始化 restore worker。

• restore worker 计算恢复数据需要读取的备份数据。

4.TiKV 恢复数据。

• Download SST：restore worker 从备份存储中下载相应的备份数据到本地。
• Rewrite KVs：restore worker 根据新建表 table ID，对备份数据 kv 进行重写，即将原有的 kv 编码中的 table ID 替换为新创建的 table ID。对 index ID，restore worker 也进行相同处理。
• Ingest SST：restore worker 将处理好的 SST 文件 ingest 到 RocksDB 中。
• Report restore result：restore worker 返回恢复结果给 BR。

5.BR 从各个 TiKV 获取恢复结果。

• 如果局部数据恢复因为 RegionNotFound 或 EpochNotMatch 等原因失败，比如 TiKV 节点故障，BR 重试恢复这些数据。
• 如果存在备份数据不可重试的恢复失败，则恢复任务失败。
• 全部备份都恢复成功后，则整个恢复任务成功。

日志备份和 PITR ( Point-in-time recovery)的架构:

日志备份的流程如下：

系统组件和关键概念：

• local metadata：表示单 TiKV 节点备份下来的数据元信息，主要包括：local checkpoint ts、global checkpoint ts、备份文件信息。
• local checkpoint ts (in local metadata)：表示这个 TiKV 中所有小于 local checkpoint ts 的日志数据已经备份到目标存储。
• global checkpoint ts：表示所有 TiKV 中小于 global checkpoint ts 的日志数据已经备份到目标存储。它由运行在 TiDB 中的 Coordinator 模块收集所有 TiKV 的 local checkpoint ts 计算所得，然后上报给 PD。
• TiDB Coordinator 组件：TiDB 集群的某个节点会被选举为 Coordinator，负责收集和计算整个日志备份任务的进度 (global checkpoint ts)。该组件设计上无状态，在其故障后可以从存活的 TiDB 节点中重新选出一个节点作为 Coordinator。
• TiKV log observer 组件：运行在 TiDB 集群的每个 TiKV 节点，负责从 TiKV 读取和备份日志数据。TiKV 节点故障的话，该节点负责备份数据范围，在 Region 重新选举后，会被其他 TiKV 节点负责，这些节点会从 global checkpoint ts 重新备份故障范围的数据。

完整的备份交互流程描述如下：

1.BR 接收备份命令 br log start。

• 解析获取日志备份任务的 checkpoint ts（日志备份起始位置）、备份存储地址。
• Register log backup task：在 PD 注册日志备份任务 (log backup task)。
• 2.TiKV 监控日志备份任务的创建与更新。
• Fetch log backup task：每个 TiKV 节点的 log backup observer 监听 PD 中日志备份任务的创建与更新，然后备份该节点上在备份范围内的数据。

3.TiKV log backup observer 持续地备份 KV 变更日志。

• Read kv change data：读取 kv 数据变更，然后保存到自定义格式的备份文件中。
• Fetch global checkpoint ts：定期从 PD 查询 global checkpoint ts。
• Generate local metadata：定期生成 local metadata（包含 local checkpoint ts、global checkpoint ts、备份文件信息）。
• Upload log data & metadata：定期将日志备份数据和 local metadata 上传到备份存储中。
• Configure GC：请求 PD 阻止未备份的数据（大于 local checkpoint ts）被 TiDB GC 机制回收掉。

4.TiDB Coordinator 监控日志备份进度。

• Watch backup progress：轮询所有 TiKV 节点，获取各个 Region 的备份进度 (Region checkpoint ts)。
• Report global checkpoint ts：根据各个 Region checkpoint ts，计算整个日志备份任务的进度 (global checkpoint ts)，然后上报给 PD。

5.PD 持久化日志备份任务状态。可以通过 br log status 查询。

PITR 的流程如下：

完整的 PITR 交互流程描述如下：

1.BR 接收恢复命令 br restore point。

• 解析获取全量备份数据地址、日志备份数据地址、恢复到的时间点。
• 查询备份数据中恢复数据对象（database 或 table），并检查要恢复的表是否存在并符合要求。

2.BR 恢复全量备份。

• 进行快照备份数据恢复，恢复流程参考恢复快照备份数据。

3.BR 恢复日志备份。

• Read backup data：读取日志备份数据，计算需要恢复的日志备份数据。
• Fetch Region info：访问 PD，获取所有 Region 和 KV range 的对应关系。
• Request TiKV to restore data：创建日志恢复请求，发送到对应的 TiKV，日志恢复请求包含要恢复的日志备份数据信息。

4.TiKV 接受 BR 的恢复请求，初始化 log restore worker。

• log restore worker 获取需要恢复的日志备份数据。

5.TiKV 恢复日志备份数据。

• Download KVs：log restore worker 根据日志恢复请求中要恢复的备份数据，从备份存储中下载相应的备份数据到本地。
• Rewrite KVs：log restore worker 根据恢复集群表的 table ID 对备份数据的 kv 进行重写 —— 将原有的 kv 编码中的 table ID 替换为新创建的 table ID。对 index ID，log restore worker 也进行相同的处理。
• Apply KVs：log restore worker 将处理好的 kv 通过 raft 接口写入 store (RocksDB) 中。
• Report restore result：log restore worker 返回恢复结果给 BR。

6.BR 从各个 TiKV 获取恢复结果。

• 如果局部数据恢复因为 RegionNotFound 或 EpochNotMatch 等原因失败，比如 TiKV 节点故障，BR 重试恢复这些数据。
• 如果存在备份数据不可重试的恢复失败，则恢复任务失败。
• 全部备份数据都恢复成功后，则恢复任务成功。

三、备份恢复工具 BR 原理

BR做的事情，简单来说，就是通过一个PD地址，找到所有的tikv-server，扫描TiKV的数据得到全局一致性的快照，存储下来；恢复也是通过一个PD地址，将备份快照恢复到TiKV中。

特点：热备份、物理备份、增量备份和恢复、数据对象备份和恢复（非全库）、远程备份、备份数据加密。

四、备份恢复工具 BR 的适用场景

• 应用场景
• 常规的一致性备份恢复
• 大规模数据迁移并有时间限制
• 只能恢复到TiDB数据库中
• 备份输出文件
• SST文件
• backupmeta文件
• backup.lock文件

五、Backup & Restore (BR) 数据迁移工具新特性

• 备份自动调节

为了减少备份任务对在线集群的影响，从 TiDB v5.4.0 起，引入了自动调节功能，此功能默认开启。在集群资源占用率较高的情况下，备份功能可以通过该功能自动限制备份使用的资源，从而减少对集群的影响。

• 批量建表

使用 Backup & Restore (BR) 执行数据恢复任务时，BR 会先在目标 TiDB 集群上创建库和表，然后再把已备份的数据恢复到表中。TiDB v6.0.0 之前，在数据恢复阶段创建表时，BR 采用了串行执行的方案。然而，当需要恢复的数据中带有大量的表（约 50000 张）时，该方案会在创建表上消耗较多时间。

为了加快创建表的速度，以减少数据恢复的时间，TiDB 在 v6.0.0 中引入了批量建表功能，此功能默认开启。

• 断点备份

快照备份会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等等一些突发情况。在 TiDB v6.5.0 之前，在错误被处理之后，之前备份的数据会作废，你需要重新进行备份。对大规模集群来说，会造成大量额外成本。

为了尽可能继续上一次的备份，从 TiDB v6.5.0 起，备份恢复特性引入了断点备份的功能。该功能可以在备份意外中断后保留上一次备份的大部分进度。

• 断点恢复

快照恢复或日志恢复会因为一些可恢复性错误导致提前结束，例如硬盘空间占满、节点宕机等等一些突发情况。在 TiDB v7.1.0 之前，在错误被处理之后，之前恢复的进度会作废，你需要重新进行恢复。对大规模集群来说，会造成大量额外成本。

为了尽可能继续上一次的恢复，从 TiDB v7.1.0 起，备份恢复特性引入了断点恢复的功能。该功能可以在意外中断后保留上一次恢复的大部分进度。

六、备份恢复工具 BR 的使用限制

1.无法恢复字符集 charset=GBK 的表到 v5.4.0 之前的 TiDB 集群

2.备份与恢复的兼容性问题

• 聚簇索引(tidb_enable_clustered_index)
• New collation(new_collations_enabled_on_first_bootstra)排序
• 全局临时表(BR v5.3.0及以上才支持)
• 版本兼容问题(check-requirements)

3.BR恢复的数据无法通过TiCDC或TiDB Binlog同步到下游

七、备份恢复工具 BR 的部署与使用

1、BR 的部署要求

• 推荐运行在 CPU:8 核，内存 16 GB 以上的节点上
• 在业务低峰时执行备份操作
• 不推荐向正在提供服务的生产集群执行恢复
• 不推荐多个BR备份和恢复任务并行运行
• BR 默认会分别在备份、恢复完成后进行数据校验

--备份时关闭校验(--checksum=false)，只在恢复时开启校验

• 推荐使用支持 S3/GCS/Azure Blob Storage 协议的存储系统保存备份数据

2、BR 的最佳实践

• 推荐在业务低峰时执行备份操作。
• 恢复期间对在线业务影响很大，建议低峰期或者限速(rate-limit) 执行恢复。
• BR 备份最好串行执行。
• BR 恢复最好串行执行。
• 推荐在-s指定的备份路径上挂载一个共享存储。
• 在使用共享存储时，推荐使用高吞吐的存储硬件

3、BR 的部署

方法一、使用TiUP 执行tiup install br 命令

查看已安装的组件

查看能安装的组件

查看能安装的br版本

安装br组件

查看安装的信息

方法二、tidb-commun ity-toolkit安装包

下载相关toolkit工具包并配置环境变量

1. 解压工具包

2.配置环境变量

$vi .bash_profile

添加如下：

export PATH=/home/tidb/.tiup/bin:$PATH:/usr/local/mysql/mysql-8.0/bin:/home/tidb/tidb-community-toolkit-v7.5.1-linux-amd64

$source .bash_profile

3.查看br命令行工具版本信息

4、BR 的使用命令

1.通过 SQL 语句

• TiDB 支持使用SQL 语句 BACKUP 和RESTORE 进行备份恢复。
• 如果要查看备份恢复的进度,可以使用SHOW BACKUPS|RESTORES 语句。

2.通过命令行工具

TiDB 支持使用BR 命令行工具进行备份恢复。

br 由多层命令组成。目前，br 包含的主要命令有：

• br backup：用于备份 TiDB 集群的全量数据。
• br log：用于启动和管理日志备份任务。
• br restore：用于恢复备份数据到 TiDB 集群。

br backup 和 br restore 还包含这些子命令：

• full：用于备份或恢复整个备份数据。
• db：用于备份或恢复集群中的指定数据库。
• table：用于备份或恢复集群指定数据库中的单张表。

常用选项

• --pd：PD 访问地址选项，例如 "${PD_IP}:2379"。
• -s 或 --storage：备份数据的存储地址选项。TiDB备份恢复支持以Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage及NFS为备份存储。关于URI格式的详细信息，请参考外部存储服务的 URI 格式。
• --ca：指定 PEM 格式的受信任 CA 的证书文件路径。
• --cert：指定 PEM 格式的 SSL 证书文件路径。
• --key：指定 PEM 格式的 SSL 证书密钥文件路径。
• --status-addr：向 Prometheus 提供统计数据的监听地址。
• --concurrency：备份或恢复阶段的任务并发数。
• --compression：备份生成文件的压缩算法，支持 lz4、snappy、zstd，默认 zstd（多数情况下无须修改）。如何选择不同的压缩算法，可以参考文档。
• --compression-level：备份选择的压缩算法对应的压缩级别，zstd 默认为 3。大多数情况下无需设置。
• --backupts：快照对应的物理时间点，格式可以是 TSO 或者时间戳，例如 400036290571534337 或者 2018-05-11 01:42:23。如果该快照的数据被垃圾回收 (GC) 了，那么 br backup 命令会报错并退出。如果你没有指定该参数，那么 br 会选取备份开始的时间点所对应的快照。

5、BR 备份恢复案例

备份到本地盘创建相关目录及属组权限(TiKV节点操作)

#mkdir -p /home/tidb/backupdata/

#chown tidb:tidb /home/tidb/backupdata/

#chmod 777 /home/tidb/backupdata/

#ls -ltr /home/tidb/

1.进行集群快照备份恢复（全库）

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

除了基础的备份和恢复功能，快照备份和恢复还提供以下功能：

• 备份指定时间点的快照数据
• 恢复指定数据库或表的数据

关于TiDB 日志备份与 PITR 使用

全量备份包含集群某个时间点的全量数据，但是不包含其他时间点的更新数据，而 TiDB 日志备份能够将业务写入 TiDB 的数据记录及时备份到指定存储中。如果你需要灵活的选择恢复的时间点，即实现 Point-in-time recovery (PITR)，可以开启日志备份，并定期执行快照（全量）备份。

详细的使用指南https://docs.pingcap.com/zh/tidb/v7.5/br-pitr-guide

集群快照（全库）备份

执行 tiup br backup full 命令，可以备份 TiDB 最新的或者指定时间点的快照数据。执行 tiup br backup full --help 可获取该命令的使用帮助。

tiup br backup full \

--pd "${PD_IP}:2379" \

--backupts '2022-09-08 13:30:00' \

--storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \

--ratelimit 128 \

--log-file backupfull.log

备注：

--pd 随意一个PD节点IP都可以

--backupts：快照对应的物理时间点。如果该快照的数据已经被 GC，那么 tiup br backup 命令会报错退出；如果没有指定该参数，br 命令行工具会选取备份开始的时间点所对应的快照。

--storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ 共享存储备份目录

--storage "local:///home/tidb/backupdata"\ 每个TiKV节点都存在相关目录（没有需要创建）并且要有读写权限777

--ratelimit 表示每个TiKV 执行备份数据任务的速度上限，单位为 MiB/s。

--log-file 表示在您当前操作命令节点的路径下生成全库备份日志，同时也会自动创建/tmp/backup目录放置备份的源数据信息（二进制）和锁定数据的信息。

注意：

BR 工具已支持自适应 GC，会自动将 backupTS（默认是最新的 PD timestamp）注册到 PD 的 safePoint，保证 TiDB 的 GC Safe Point 在备份期间不会向前移动，即可避免手动设置 GC。

备份期间终端会显示进度条，效果如下。当进度条达到 100% 时，表示备份完成。

查询快照备份的时间点信息

出于管理备份数的需要，如果你需要查看某个快照备份对应的快照物理时间点，可以执行下面的命令：

tiup br validate decode --field="end-version" \

--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1

关于备份文件

快照备份会产生如下类型文件：

• SST 文件：存储 TiKV 备份下来的数据信息。单个 SST 文件大小等于 TiKV Region 的大小。
• backupmeta 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值。
• backup.lock 文件：用于防止多次备份到同一目录。

SST 文件会根据 storeID 划分子目录。目录结构如下：

集群快照（全库）恢复

br restore full \

--pd"${PDIP}:2379" \

--storage "local:///home/tidb/backupdata" \

--ratelimit 128 \

--log-file restorefull. log

备注：备份到本地的时候每个TiKV只备份自己节点的数据，恢复的时候需要全部的数据，因此需要汇聚全部数据到该目录下。使用scp命令传输。共享存储不需要。

注意

如果没有挂载 NFS 到 br 工具或 TiKV 节点，或者使用了支持 S3、GCS 或 Azure Blob Storage 协议的远端存储，那么 br 工具备份的数据会在各个 TiKV 节点生成。注意这不是推荐的 br 工具使用方式，因为备份数据会分散在各个节点的本地文件系统中，聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到 SST file not found 报错。

恢复期间终端会显示进度条，效果如下。当进度条达到 100% 时，表示恢复完成。在完成恢复后，br 工具为了确保数据安全性，还会校验恢复数据。

登录数据库前后对比如下图：

恢复单个数据库的数据

要将备份数据中的某个数据库恢复到集群中，可以使用 br restore db 命令。以下示例只恢复 test 库的数据：

tiup br restore db --pd "${PD_IP}:2379" \

--db "test" \

--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

登录数据库前后对比如下图：

恢复单张表的数据

要将备份数据中的某张数据表恢复到集群中，可以使用 br restore table 命令。以下示例只恢复 test.usertable 表的数据：

tiup br restore table --pd "${PD_IP}:2379" \

--db "test" \

--table "usertable" \

--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

使用表库过滤功能恢复部分数据

要通过复杂的过滤条件恢复多个表，可以使用 br restore full 命令，并用 --filter 或 -f 指定表库过滤的条件。以下示例恢复符合 db*.tbl* 条件的表的数据：

tiup br restore full --pd "${PD_IP}:2379" \

--filter 'db*.tbl*' \

--storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"

登录数据库前后对比如下图：

恢复 mysql 数据库下的表

备注：自 br v5.1.0 开始，快照备份会备份 mysql schema 下的系统表数据，而不会默认恢复这些数据。自 br v6.2.0 开始，在设置 --with-sys-table 下，恢复数据时将同时恢复部分系统表相关数据。

详细见链接：https://docs.pingcap.com/zh/tidb/v7.5/br-snapshot-guide

2. 进行单库备份恢复

单库备份

br backup db \

--pd "${PDIP}:2379" \

--db test \

--storage "local:///home/tidb/backupdata"

--ratelimit 128 \

--log-file backup_db. log

单库恢复

br restore db \

--pd "${PDIP}:2379" \

--db "test" I

--storage "local:///home/tidb/backupdata"

--log-file restore_db. log

3. 进行单表备份恢复

单表备份

br backup table \

--pd "${PDIP}:2379" \

--db test \

--table usertable \

--storage "local:///home/tidb/backupdata" \

--ratelimit 120 \

--log-file backup_table. log

单表恢复

如果你需要用复杂的过滤条件来恢复多个表，执行br restore full命令，并用--filter或-f指定使用表库过滤。

br restore table \

--pd "${PDIP}:2379" \

--db "test" \

--table "usertable" \

--storage "local:///home/tidb/backupdata" \

--log-file restore_table. log

4. 进行多表备份恢复

多张表备份

br backup full \

--pd "${PDIP}:2379" \

--filter ‘db*.tbl*’ \

--storage "local:///home/tidb/backupdata" \

--ratelimit 128 \

--log-file backupfull. log

备注：br backup full 表示全部

--filter ‘db*.tbl*’ 表示过来db开头的数据库中tbl开头的表

多张表恢复

br restore full \

--pd "${PDIP}:2379" \

--filter ‘db*.tbl*’ \

--storage "local:///home/tidb/backupdata" \

--log-file restorefull. log

5. 进行增量备份与恢复

增量备份

首次增量备份必须有全量备份，设置上一次的备份目录（首次为全量备份目录）

LAST_BACKUP_TS=`br validate decode --field="end-version" -s local:///home/tidb/backupdata| tail -n1`

备份增量，只需要在备份的时候指定上一次的备份时间戳--lastbackupts即可。

br backup full\

--pd ${PDIP}:2379 \

-storage “local:///home/tidb/backupdata/incr”\

--lastbackupts ${LAST_BACKUP_TS}

备注：区分开全量备份目录为local:///home/tidb/backupdata，增量备份目录为local:///home/tidb/backupdata/incr

差异增量备份，累计增量备份，区别是每次都和增量比还是和全量比。

增量恢复

增量恢复的方法和使用BR 进行全量恢复的方法并无差别。需要注意，恢复增量数据的时候，需要保证备份时指定的 lastbackupts 之前备份的数据已经全部恢复到目标集群。

首先恢复全量备份上面案例有

全库恢复

br restore full \

--pd"${PDIP}:2379" \

--storage " local:///home/tidb/backupdata " \

--ratelimit 128 \

--log-file restorefull. log

备注：备份到本地的时候每个TiKV只备份自己节点的数据，恢复的时候需要全部的数据，因此需要汇聚全部数据到该目录下。使用scp命令传输。

再次恢复增量备份

br restore full\

--pd ${PDIP}:2379 \

-storage “local:///home/tidb/backupdata/incr”\

--ratelimit 128 \

--log-file restore_incr. log

6、BR 备份恢复性能与影响

快照备份的性能与影响

TiDB 备份功能对集群性能（事务延迟和 QPS）有一定的影响，但是可以通过调整备份的线程数 backup.num-threads，以及增加集群配置，来降低备份对集群性能的影响。

你可以通过如下方案手动控制备份对集群性能带来的影响。但是，这两种方案在减少备份对集群的影响的同时，也会降低备份任务的速度。

• 使用 --ratelimit 参数对备份任务进行限速。请注意，这个参数限制的是把备份文件存储到外部存储的速度。计算备份文件的大小时，请以备份日志中的 backup data size(after compressed) 为准。设置 --ratelimit 后，为了避免任务数过多导致限速失效，br 的 concurrency 参数会自动调整为 1。
• 调节 TiKV 配置项 backup.num-threads，限制备份任务使用的工作线程数量。内部测试数据表明，当备份的线程数量不大于 8、集群总 CPU 利用率不超过 60% 时，备份任务对集群（无论读写负载）几乎没有影响。
• 通过限制备份的线程数量可以降低备份对集群性能的影响，但是这会影响到备份的性能，以上的多次备份测试结果显示，单 TiKV 存储节点上备份速度和备份线程数量呈正比。在线程数量较少的时候，备份速度约为 20 MiB/线程数。例如，单 TiKV 节点 5 个备份线程可达到 100 MiB/s 的备份速度。

快照恢复的性能与影响

• TiDB 恢复的时候会尽可能打满 TiKV CPU、磁盘 IO、网络带宽等资源，所以推荐在空的集群上执行备份数据的恢复，避免对正在运行的业务产生影响。
• 备份数据的恢复速度与集群配置、部署、运行的业务都有比较大的关系。在内部多场景仿真测试中，单 TiKV 存储节点上备份数据恢复速度能够达到 100 MiB/s。在不同用户场景下，快照恢复的性能和影响应以实际测试结论为准。

八、问题总结

问题一、恢复时提示需要drop existing databases and tables

解决办法：

恢复之前删掉之前库

问题二、恢复时提示节点目录、文件不存在

解决办法：

本地备份时需要重建相同的目录属组和权限；恢复需要完整的备份文件。因此生产环境推荐使用支持 S3/GCS/Azure Blob Storage 协议的存储系统保存备份数据

问题三、BR 恢复特定时间单表单库，需要全库恢复，无法做到精准恢复

解决办法：

考虑别的备份恢复方式，或者等待BR下一版本实现。