数据库作为基础设施，其安全性不言而明，数据安全备份和恢复功能就成为在严肃使用场景下的标配。TiDB 作为一款分布式数据库，目前可以满足超大集群的备份恢复的需求，经过测试，10T 数据的备份恢复速度可以达到 GB/s。
这得益于我们研发的分布式备份恢复工具 Backup&Restore That Scales（以下简称 BR）。如果你业务产生海量数据，并极度重视数据安全、备份恢复的效率，那么 TiDB + BR 值得一试，从此再也不怕“删库跑路、恢复缓慢”。
10T 测试
让我们先来秀一下肌肉吧！我们使用 BR 备份恢复了一个 10T 数据量的超大集群[1]：
- 备份速度：548MB/s * TiKV 节点数。
- 恢复速度：150MB/s * TiKV 节点数。
光说这两个数字可能不直观，所以我们特地把真实发生的备份恢复截了图，放在这让大家感受下。
备份
图片说明：备份了两张表，绿线是整体的备份速度，其余线条是各个 TiKV 节点备份速度。
11:15 和 11:28 在备份索引数据，由于索引数据内容较短，所以备份速度有些下降。
恢复
图片说明：恢复了之前备份下来的两张表，同样的绿线是整体速度，其他线条为各个 TiKV 节点恢复速度。
恢复期间的毛刺是因为我们将恢复任务拆分成一个个小任务，各个小任务之间串行（潜在优化点）执行。1:00 和1:15 恢复速度下降同样也是由于索引内容较短导致。
分布式数据库备份恢复的难点
备份恢复一直是超大 TiDB 集群的难题：TiDB 存储层的分布式架构实现没有一致的物理快照的概念。
由于 TiDB 兼容 MySQL 协议，我们曾经考虑过使用 mydumper/myloader 作为备份恢复工具（MySQL 社区常用的备份恢复工具）， 但是，mydumper 面对超大规模的 TiDB 集群就显得有些捉襟见肘，不仅无法合理利用集群资源来提升备份速度，严重影响业务的请求，还有一定概率造成 TiDB OOM。
我们曾经也针对 TiDB 优化了类似 myloader 工具：loader。根据之前的测试[2]，loader 恢复 1TB 的数据大概需要 19 个小时。但是这个速度难以满足我们对恢复性能的追求，只要原因是恢复流程走 SQL，流程长，添加了大量没必要的计算，导致资源不能被充分利用。
总之，mydumper 和 loader 虽然能用，但没有完美契合 TiDB。因此，我们决心开发新的备份恢复工具，BR。
设计与实现
水平扩展
是的，BR 让备份和恢复能够水平扩展！
BR 和 mydumper 最大的不同点在于它直接从 TiKV（存储层）入手，“用对的方法做对的事”。BR 将备份和恢复任务下推到各个 TiKV 执行（类似于 Coprocessor 下推），比如一个备份任务可能跨越了多个 Region，BR 只需给每个 TiKV 下发一个请求，就能让各个 TiKV 自行备份它上面的数据。BR 将备份恢复带来的 CPU 和 IO 均匀的分散在各个 TiKV 上，轻松备份恢复上百个节点的 TiDB 集群。
强一致性
满足一致性要求是备份恢复工具的及格线。
Snapshot Isolation 即是 TiDB 所提供的一致性，也是 BR 的备份恢复所提供一致性。数据分散在多台 TiKV 节点，BR 是如何做到 Snapshot Isolation 呢？其实很简单，BR 只需取一个 TiDB 事务的 Timestamp，然后发到所有 TiKV 上。TiKV 将这个 Timestamp 的能看到的数据备份即可，这里的数据不仅包含了用户的数据，也包含了 TiDB 的元数据，比如 Table schema 等，所以 BR 备份在满足存储层（TiKV）一致性的同时也能满足 SQL 层（TiDB）的一致性。
体验一下？
如果你手头恰好跑着 TiDB 集群，集群数据恰好上了 TB，又恰好苦于没法快速备份恢复，那么不妨试试 BR。我们已经陆续更新了一些文档，供大家参考：
BR 目前还处于 beta 阶段，如果在使用过程中发现了任何问题，欢迎反馈到 https://github.com/pingcap/br/issues
[1]: 五台 Intel® E5-2630v4, Intel® SSD P4510 4TB 物理机，每台部署一个 TiKV，使用本地模式进行备份恢复。备份数据库逻辑大小 3.34T，三副本物理大小 10.1T。备份并发参数 16，恢复并发参数 128。恢复速度受 Region 调度影响比较大，不包含调度，速度为 279MB/s。