BR 全称为 Backup & Restore，是 TiDB 分布式备份恢复的命令行工具，用于对 TiDB 集群进行数据备份和恢复。BR 只支持在 TiDB v3.1 及以上版本使用。
相比 Dumpling，BR 更适合大数据量的场景。
本文介绍了 BR 的工作原理、推荐部署配置、使用限制以及几种使用方式。
BR 将备份或恢复操作命令下发到各个 TiKV 节点。TiKV 收到命令后执行相应的备份或恢复操作。
在一次备份或恢复中，各个 TiKV 节点都会有一个对应的备份路径，TiKV 备份时产生的备份文件将会保存在该路径下，恢复时也会从该路径读取相应的备份文件。
更多信息请参阅备份恢复设计方案。
备份路径下会生成以下两种类型文件：
backupmeta 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值backup.lock 文件：用于防止多次备份到同一目录SST 文件以 storeID_regionID_regionEpoch_keyHash_cf 的格式命名。格式名的解释如下：
default 或 write）下面是使用 BR 进行备份恢复的几条限制：
new_collations_enabled_on_first_bootstrap 开关值相同的集群之间进行操作。这是因为 BR 仅备份 KV 数据。如果备份集群和恢复集群采用不同的排序规则，数据校验会不通过。所以恢复集群时，你需要确保 select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled'; 语句的开关值查询结果与备份时的查询结果相一致，才可以进行恢复。BR 和 TiDB 集群的兼容性问题分为以下两方面：
下表整理了会导致 KV 格式发生变化的功能。
| 功能 | 相关 issue | 解决方式 |
|---|---|---|
| New collation | #352 | 确保恢复时集群的 new_collations_enabled_on_first_bootstrap 变量值和备份时的一致，否则会导致数据索引不一致和 checksum 通不过。 |
| 恢复集群开启 TiCDC 同步 | #364 | TiKV 暂不能将 BR ingest 的 SST 文件下推到 TiCDC，因此使用 BR 恢复时候需要关闭 TiCDC。 |
在上述功能确保备份恢复一致的前提下，BR 和 TiKV/TiDB/PD 还可能因为版本内部协议不一致/接口不一致出现不兼容的问题，因此 BR 内置了版本检查。
BR 内置版本会在执行备份和恢复操作前，对 TiDB 集群版本和自身版本进行对比检查。如果大版本不匹配（比如 BR v4.x 和 TiDB v5.x 上），BR 会提示退出。如要跳过版本检查，可以通过设置 --check-requirements=false 强行跳过版本检查，但是这样可能会引入版本不兼容的问题。TiDB v4.0 用 BR 备份后，不完全支持恢复到 v5.0 以及之后版本，详细信息见 BR 版本检查（stable 版文档）。
运行 BR 的最低机型配置要求如下：
| CPU | 内存 | 硬盘类型 | 网络 |
|---|---|---|---|
| 1 核 | 4 GB | HDD | 千兆网卡 |
一般场景下（备份恢复的表少于 1000 张），BR 在运行期间的 CPU 消耗不会超过 200%，内存消耗不会超过 1 GB。但在备份和恢复大量数据表时，BR 的内存消耗可能会上升到 3 GB 以上。在实际测试中，备份 24000 张表大概需要消耗 2.7 GB 内存，CPU 消耗维持在 100% 以下。
下面是使用 BR 进行备份恢复的几种推荐操作：
rate-limit) 执行恢复。-s 指定的备份路径上挂载一个共享存储，例如 NFS。这样能方便收集和管理备份文件。目前支持以下几种方式来运行 BR 工具，分别是通过 SQL 语句、命令行工具或在 Kubernetes 环境下进行备份恢复。
在 v4.0.2 及以上版本的 TiDB 中，支持直接通过 SQL 语句进行备份恢复，具体使用示例见：
在 v3.1 以上的 TiDB 版本中，支持通过命令行工具进行备份恢复。
首先需要下载一个 BR 工具的二进制包，详见下载链接。
通过命令行工具进行备份恢复的具体操作见使用备份与恢复工具 BR。
目前支持使用 BR 工具备份 TiDB 集群数据到兼容 S3 的存储、Google Cloud Storage 以及持久卷，并作恢复：