作者：李坤
BR 备份概述
备份是所有运维人员必须重视的操作，任何数据库都需要备份，TiDB 也不例外。不过一直以来 TiDB 只支持最简单的 Mydumper 备份，而没有类似物理备份的方式。 Mydumper 是逻辑备份，导出的是 SQL 语句，速度慢，占用空间大。由于备份速度慢， 备份之前还需要把 GC 时间设置得巨大，否则备份中途也会失败。在大规模的 TiDB 分布式集群上备份，随着集群越来越大，Mydumper 备份会越来越难。
TiDB 一直没有做物理备份，因为确实有难度，也没有太多可以借鉴的工业产品。物理备份通常是要扫描物理文件来实现，作为一个集群整体，虽然数据是分布的，必须要保证各个节点的外部一致性，做到全局一致的快照备份恢复。
而对应到传统的分库分表方式，单机数据库的备份在一致性上有待商榷的。比如 MySQL 常用的 Xtrabackup 物理备份工具，只能备份分库分表的一个分片，多个分片需要备份多次，多个备份集是没有关联的，不同时间点的，这样备份集在全局来看就是不一致的。
说了这么多，终于到 BR 上场了，它正是 TiDB 用户呼唤多年的类物理备份方式， BR 解决了海量数据的一致性备份，提高数据安全，注重备份恢复的效率。
BR 的功能特性
BR 做的事情，简单来说，就是通过一个 PD 地址，找到所有的 tikv-server，扫描 TiKV 的数据得到全局一致性的快照，存储下来；恢复也是通过一个 PD 地址，将备份快照恢复到 TiKV 中。
BR 是以命令行 Cli 的方式提供，用于对 TiDB 集群进行数据备份和恢复。备份的功能比较多，目前 BR 可以做到以下功能。包括
- 整个集群的全量备份、全量恢复，
- 指定数据库的全量备份恢复，
- 某个数据库下指定表的全量备份恢复，
- 支持从全量备份中恢复单表
- 以及以上方式的增量备份
恢复目前只支持恢复到全新集群，未来也会支持在线恢复。当然，如果确认数据没有冲突，可以恢复，比如恢复一张不存在的表，否则会有数据冲突。
BR作为大集群的备份恢复工具，可以为百 T 甚至更大的集群备份。备份速度是一个非常重要的指标。BR 的优势是，在备份和恢复的操作上，是并行的，每个 tikv-server 节点同时在执行数据扫描备份。因此，如果集群变大，tikv-server 也会变多，对备份速度不会有太大的影响，当然也要考虑备份目标端的吞吐性能上限。备份的数据支持直接通过通用 S3 接口存储，也支持使用网络存储，如 NFS、NAS 等。
备份/恢复速度的指标，经过测试，在极限情况下，单个 tikv-server 可以达到 150 MB/s 。当然实际生产环境的线上备份，是不能让备份影响线上业务的，BR 也支持限速备份，可以根据自己业务的敏感度设置。
图例：不限速时，备份对集群 QPS 的影响
另外，备份安全也是一个很重要的指标，目前 BR 已经支持 CA 以及 SSL 的安全信任证书。
注意事项：
- 暂不支持备份/恢复的断点续传
- 备份需要保证在 GC 时间以内完成，可以调大参数 tikv_gc_life_time
- 强烈建议使用网络存储，不要将备份集放在本地磁盘上
- 在恢复前确定没有同名数据库/表存在
四、BR 原理和执行流程
全量备份的基本流程：
我们拥有一个 TiDB 集群。为了保证我们备份到某个“一致性快照”，首先：
- BR 与 PD 通信，从 PD 获取当前 TS，用作 backup_ts。
- 依照 backup_ts 来获取当时的 schema。
然后 BR 也从 PD 获取到所有 TiKV 的信息，依照用户的需求来构建需要备份的表的 Key range，使用 TiKV 提供的接口，来将备份任务“下推”到 TiKV 集群中。
在 TiKV 端，收到这个消息之后，会找到这个 Key Range 所在的所有 Regions Leader，利用 start_version 和 end_version 根据 backup_ts 获取 MVCC 中的一个快照，获取所需的键值对记录，全量备份的时候，可以忽略掉 Delete 记录。
TiKV 最终将键值对写入指定的 SST 文件中，将备份结果返回给 BR 端，由此让 BR 端可以获得一些统计信息还有 checksums，存储在 backupmeta 文件中给恢复使用，备份流程结束。
关于备份的空间占用，由于 sst 本身已经是压缩后的内容， BR 没有再进一步压缩，会按照原压缩算法写 sst，所以通常备份的结果集，与单副本数据相差不大。
图例：架构图
恢复逻辑
恢复的逻辑，简单来说就是把备份出来的 SST ，以及备份的 schema 写入到目标 TiKV 的 RocksDB 数据库中。
增量备份
用户指定 lastbackupts 之后，BR 就会备份从 lastbackupts 到 backup_ts 之间的增量数据。
需要注意的是，在全量备份和增量备份之间，或者两次增量备份之间，有可能会发生 MVCC 的 GC，因此在增量备份的时候，我们必须赶在 GC 之前备份。
通常建议备份之前，将 GC 时间调大，备份后在调整回来；另一方面，自适应的 GC 时间的提案亦已经就绪。
BR 后续规划
- 支持在线恢复功能
- 使用 SQL 执行 BR，提高易用性
- 支持更多的存储方式，NBU、GCS、etc …
- 更高的恢复速度
- Recover 的断点续传
- 自适应的 GC
六、BR 在用户的测试使用情况
在上月的 TiDB Devcon 2020 活动中，有多名用户也介绍了 BR 的使用经验，这里节选出转转和爱奇艺的工程师的使用经验。
转转-TiDB 4.0 新特性在电商行业的探索 （11’51"-13’17")
爱奇艺- TiDB 在高速增长视频业务中的应用（13’57"-15’05")
以上，是不是想赶快动手用起来呢？ BR 的使用也是非常简单的，参考 「BR 备份与恢复场景示例」来使用起来吧！
BR 备份与恢复场景示例
PingCAP Docs