【51CTO.com快译】云原生应用时代下，对备份体系进行调整无疑已经成为一种必然。然而，即使逐步淘汰了原有备份与负责处理相关任务的脚本，大家仍会发现各类下一代应用程序及数据库（包括Apache Cassandra、MongoDB、Amazon DynamoDB、微软DocumentDB、Apache HBase等等）在备份与恢复方面的表现令人沮丧。为什么会这样？
简而言之：在任何拥有最终一致性特征的非关系数据库架构当中，我们几乎都不可能捕捉到具备一致性状态的备份副本。而以此为基础实现成功的数据恢复更是几近不可能。
究其原因，首先应考虑到分布式架构的基本性质。此类架构旨在扩展并抵御节点故障，尽可能降低停机机率。而在对分布式架构进行备份时，主要存在以下几项挑战：
- 数据被写入至某一可用节点。数据的***着陆点无法预测，因此无法在数据被写入节点的同时对其进行捕捉。
- 此后，数据被复制到至少一个其它节点当中，而后方进行验证。这确保了有效写入，同时亦立即为数据创建副本。
- 接下来将数据复制到更多节点中以实现可用性。这一步完成后，同一数据可快速连续进行更新。
- 意味着任意时段同一数据都至少拥有3到4套副本。
- 且各节点始终不存在即时一致性。
- 如果对各套副本进行分别备份，则效率明显极为低下。
- 而在任一节点发生故障时，其拓扑结构也将立即发生变化。
在理论上，出色的DevOps团队能够编写对应脚本，确保在80%到90%的时段内成功实现数据库备份（不过考虑到多节点故障、拓扑变更、数据库压缩等情况的存在，脚本编写难度极大）。
然而遗憾的是，备份本身只是这一议程当中较“容易”的部分。事实上，恢复才是问题的关键所在。成功的恢复机制要比大多数人想象中的复杂得多。其涉及以下具体流程：
- 重构正确拓扑。由于各个节点皆单独备份，因此数据库必须恢复到与备份时对等的拓扑状态（6节点对6节点，12节点对12节点），而其中必然涉及跨云环境、测试/开发与持续集成/持续交付等用例。
- 等待数据库进行修复与恢复。非关系数据库体系能够承受节点故障并保持正常运行，然而这种具备数据协调能力的架构在恢复方面则表现糟糕，特别是在配合低速存储驱动器的情况下。
- 重复数据删除引发多套不一致版本。备份副本可能拥有三套甚至更多处于不一致状态的全部数据副本，因此需要首先进行重复数据删除或者一致化处理。
- 数据历史并非始终可用。在大多数分布式架构当中，oplog都作为循环缓冲区存在，其会在运行当中不断覆盖自身内容。有时候，我们甚至无法恢复必要的日志数据以实现数据库协调。
- 并不具备可靠的方法以返回某时间点。即使使用oplog数据，我们仍然很难重建特定时间点数据。在最理想的情况下，大家只会获得一套时间点较近且相对精确的数据库副本。
在现实世界当中，即使数据能够得到恢复，整个周期也可能需要数天乃至数周。然而最近GitLab由于误删导致主数据库数据丢失的事故证明，即使技术水平极高的组织机构也很难顺利处理这一难题。而如果缺少可靠的备份与恢复流程，人为错误有可能与自然灾害一样对数据库产生致命影响。
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
