Uber 利用存储技术来运行其实时业务。这包括将在线数据存储在开源数据库中，例如 MySQL、 Apache Cassandra 、etcd和Apache Zookeeper ，以及 Uber 自研的存储解决方案，例如托管在Uber 有状态平台上的Docstore 和 Schemaless。数据库备份恢复对于 Uber 的业务连续性和灾难恢复至关重要。它支持多种用例，例如缓解业务中断、从数据损坏中恢复以及取证和合规性。此外，它还支持模拟生产环境，用于负载测试、数据完整性和安全性测试。

Uber 的在线存储解决方案拥有数十 PB 的数据容量，用于支持关键业务运营。这些解决方案每秒可处理数百万至数十亿次请求，覆盖 Uber 的全球各个业务领域。如此庞大的规模使得 Uber 能够以不同的时间间隔从数据库中备份近 100 PB 的数据，TB 级到 PB 级的数据可以在几分钟到几小时内恢复。 

这篇博客介绍了 Uber 针对在线数据库开发的强大备份恢复系统的最新进展。

大规模改进 Uber 的备份恢复系统面临诸多挑战：

• 原始的备份调度：以前，备份的调度方式很简单，就是周期性地尽力执行备份。这种方式没有考虑当前的网络资源、主机资源、优先级、速率限制或系统可观测性。这导致备份工作负载利用率出现峰值波动，引发多种问题，需要缓慢的机制来恢复备份。

   

• 临时恢复流程：恢复流程没有系统性地定义，而是以未经检查的脚本或过时的运行手册的形式存在。随着数据库系统定期升级，该流程很容易失效。

   

• 缺乏恢复演练：没有定义恢复流程或系统工作负载。此外，也没有定期演练来验证恢复功能是否正常。 

   

• 新的恢复目标：过去，某些技术的恢复点目标 (RPO) 为 7-21 天，而恢复时间目标 (RTO) 对于大型数据库而言则从未知到数天不等。随着调度层、各种基础架构层以及特定技术备份和恢复流程的多项优化，大多数数据库已转向需要可靠的备份。RPO 已缩短至 4-24 小时，RTO 已缩短至每小时 300 TB。 

这篇博客介绍了我们为应对这些挑战而实施的一些优化措施。

Uber 有状态平台之上的增强型备份恢复系统，通过抽象化管理备份恢复生态系统及其底层组件的各个方面，提供统一的体验。这些方面包括针对整个有状态数据库集群的备份工作负载进行集中式自适应调度。每个备份工作负载都会备份当前数据库快照，并进行整体状态传播，同时监控备份过程。在恢复方面，系统会定期进行恢复测试，以验证现有备份与底层恢复自动化流程的完整性和正确性。总而言之，这构建了CBCR（持续备份持续恢复）框架的概念。

备份恢复系统采用基于快照的备份和恢复架构来管理有状态集群，从而提高灾难恢复能力。 

图 1：有状态集群的连续备份恢复

备份恢复系统包含以下组件：

• 持续备份：一个集中式协调器，用于定期在有状态技术中调度备份，并可配置数据库备份策略。这能够自适应地分散备份工作负载，从而确保网络可靠性和安全性。

   

• 持续恢复：一个集中式协调器，用于定期测试跨有状态技术的恢复操作，并可配置数据库恢复策略。它通过验证备份快照的正确性和完整性，确保恢复工作负载的健康运行。

   

• 备份框架：一个统一的备份驱动程序，集成了存储数据库特定的插件，以执行数据库快照逻辑并上传到 Uber 的 blob 存储。 

   

• 恢复框架：统一的恢复驱动程序集成了存储数据库特定的插件，以执行备份下载和将快照加载到数据库。 

   

• 技术主流工作负载：任何有状态技术都包含主流组件，例如技术管理器/工作节点、数据库工作负载以及其他对业务运营至关重要的辅助工作负载。管理器/工作节点负责协调并遵循目标状态驱动的架构。 

   

• Uber Blobstore：一个专为大规模上传/下载而构建的对象存储后端，具有可配置的策略。它可作为多种云存储选项之上的虚拟化层。

持续备份功能可对所有数据库进行持续可靠的备份。它既能以足够的频率进行备份，又能降低存储成本和网络利用率。 

Time Machine是持续备份框架的关键组件，它作为集中式备份协调器，运行着全局自适应调度器，定期触发备份工作负载。该系统每天至少上传数 PB 的数据。Uber 的网络带宽在多个 Uber 关键业务工作负载的在线/离线流程中共享。Time Machine 解决了如何在不中断服务堆栈网络使用的情况下自适应地调度备份的难题。 

Time Machine 拥有一个最优选择引擎，内置客户端速率限制功能，用于决定在给定的调度周期内备份哪些数据库。它会考虑多种信号，例如：

• 备份新鲜度标准

• 动态网络和主机基础设施可用性 

• 备份消耗的历史趋势 

• 企业高峰/低谷网络利用率

• 根据存储技术制定备份速率限制策略，优先备份关键数据库

• 地理位置、其可用性和利用率

这种智能调度机制能够高效、均匀地大规模分配整个数据库备份任务。在做出最优选择后，Time Machine 会调用特定于数据库的触发器来启动运行时备份工作负载，从而提供可靠的备份、完整性和保护。

图 2：有状态平台上的持续备份

备份过程遵循以下步骤： 

• 持续备份（或时间机器）有一个全局调度程序模块，该模块会定期运行以调度备份工作负载。

   

• 备份调度程序在每个周期内调用 3 个连续阶段：发现、选择和触发。

• 发现阶段会对整个有状态存储集群进行全集群扫描，以收集所有可能的数据库进行备份。 

• 选择阶段应用决策标准（多项筛选和排序规则）来确定最终需要备份的数据库集合。这使得该过程能够适应网络和主机基础设施的可靠性。 

• 触发阶段决定备份模式（完整备份或增量备份），并根据特定技术的行为调用备份工作负载。

• 技术插件接口是针对每种存储技术定义的，用于执行持续备份阶段所需的各种操作。这些操作包括数据库级元数据、备份历史记录、正在运行的备份工作负载以及当前集群状态。

   

• 对于每个备份触发事件，由Uber 有状态平台支持的相应技术特定的管理器/工作进程会协调整个备份工作负载。它支持按需生成备份边车工作负载，并共享期望状态。然后，它会验证备份的完整性，并将实际状态发布到有状态元数据存储中。 

   

• 对于任何存储技术，每个备份工作负载都会执行数据库快照逻辑并上传到 Uber 的 blob 存储。

图 3：备份框架控制流程

Backup框架是一个通用备份驱动程序，集成了特定技术的插件，用于执行数据库快照逻辑，并高效可靠地上传到 Uber 的 Blob 存储。运行时备份工作负载作为按需 sidecar 容器运行，与主流容器（例如技术节点工作容器和数据库容器）并行运行。节点是运行在由主机集群支持的容器化 cgroup 中的有状态工作负载单元，遵循目标状态驱动架构。 

以下是备份流程： 

• 对于任何数据库，节点工作进程都作为主要工作负载，负责数据库的编排和健康维护。它将传入备份的目标状态作为运行时备份工作负载的输入，并监控备份的整个生命周期。

• 备份驱动程序负责协调数据库快照文件的提取和备份。它以增量方式上传这些文件，并进行速率限制和数据完整性检查，同时将上传文件的状态记录到备份索引中。上传完成后，它会清理这些文件，以避免磁盘使用量激增。

• 备份驱动程序还会将备份索引推送到 Blob 存储，这有助于对快照版本之间的不可变文件进行去重，从而构建增量/差异备份。它会引用所有文件，形成逻辑上完整的备份。

• 备份驱动程序监控钩子会在节点资源被高度利用时终止进程，以避免中断生产流量。

• 备份驱动程序完成，通过备份 I/O 卷将实际状态共享回工作进程，最终同步回有状态元数据存储。

以下是每种技术的数据库快照逻辑工作原理：

• 基于 MySQL 的存储技术使用Percona Xtrabackup快照工具包。这包括 MySQL和Uber 自研的 Docstore/Schemaless 技术，并提供定制化的高效差异备份解决方案。 

• Cassandra 使用类似Medusa 的差异备份设置，并使用 nodetool 快照工具包。 

• etcd 使用etcd-clientv3来获取时间点快照。 

• Zookeeper 会备份最新的 snapshot.<zxid>文件。

恢复框架与备份框架类似，采用技术无关的设计，旨在实现自动化和一致的恢复。其模块化设计使其具有可扩展性，并能适应不同的数据库架构。此外，该框架无需人工干预，缩短了恢复时间，并最大限度地降低了就地恢复和异地恢复场景中人为错误的风险。

该框架提供了一个通用驱动程序，并带有可扩展的、特定于数据库技术的插件，用于定义关键组件。清单提供程序插件经过定制，可获取如上所述的特定于数据库的备份索引清单，其中每个备份都与一个详细的备份索引相关联。备份索引引用来自不同备份类型（完整备份、增量备份或差异备份）的所有快照文件以及恢复期间所需的文件。数据库加载程序定义了针对数据库架构（MySQL、Cassandra、etcd）定制的数据库导入逻辑，以使数据库达到可用状态。

以下是每种技术的数据库加载过程：

• 基于 MySQL 的恢复过程使用 Percona XtraBackup 等工具提取和准备备份，以便 MySQL 可以使用正确的数据和设置顺利启动。

• Cassandra 恢复操作包括下载备份文件（通常是 SSTable），并将其加载到 Cassandra 引擎中。

• etcd/Zookeeper 恢复过程类似，即将备份快照放入其指定的数据库目录中，并利用其特定的快照加载器库。

图 4：恢复框架控制流

Restore 框架与 Continuous Restore 框架的集成有助于持续验证并为真实世界的情况做好准备。

持续恢复框架通过频繁验证已恢复的备份来确保数据的完整性和正确性。该框架提供智能调度功能，可配置恢复测试节奏，从而实现定期和临时验证。调度逻辑会考虑硬件资源可用性，以避免对生产环境造成影响。 

恢复测试策略包括专用数据库测试和随机数据库测试。专用测试使用预定义的、包含已知数据的数据库，执行详细的端到端恢复和验证。随机测试则选择具有特定特征的生产规模数据库，以便在真实环境下更广泛地验证恢复工作流程。

恢复后，该框架会执行强大的数据验证，包括文件完整性验证和针对已知专用数据库的逐字节数据比较。此外，该框架还会收集详细的分析数据，包括恢复成功率、基于备份数据的恢复率、数据完整性验证结果以及多个性能指标，并将这些数据报告给监控和分析部门。

修复评估过程分为四个阶段：

• 发现/选择：根据层级、大小和上次成功备份时间等标准，识别符合恢复测试条件的数据库。应用过滤和优先级规则来确定要恢复的数据库，从而实现工作负载的均衡分配。此外，该过程还考虑了恢复评估策略（专用或随机），从而为评估框架提供了灵活性。

• 触发阶段：通过创建临时集群进行测试来执行恢复过程。它会设置一个新集群并触发恢复，利用可扩展恢复框架。此阶段充当被测系统，负责从备份中执行实际的恢复操作。

• 验证：根据恢复评估策略运行验证。对于专用数据库，将数据与预定义的数据集进行比较。对于随机数据库，验证备份完整性。

• 报告：测试完成后，系统会生成详细报告，并清理测试过程中创建的任何临时资源。

图 5：有状态集群中的持续恢复框架

持续恢复框架的优势包括： 

• 运行弹性：系统具备恢复能力，降低了停机风险。

• 合规和审计支持：生成自动报告以满足回收和合规要求。

• 数据保障：验证数据完整性和恢复过程，以提高可靠性。

• 可操作的见解：提供恢复性能的可见性，并突出显示潜在的改进领域。

通过不断验证恢复流程，我们的框架加强了灾难恢复准备工作，保护了关键数据，并增强了系统大规模恢复能力。