【.com速译】在云原生应用时代，对备份系统进行调整无疑是必不可少的。然而，即使逐步淘汰了遗留备份和负责处理相关任务的脚本，您仍然会发现各种下一代应用程序和数据库（包括ApacheCassandra、MongoDB、AmazonDynamoDB、MicrosoftDocumentDB、ApacheHBase等）。)复苏惨淡。为什么？简而言之：在任何具有最终一致性的非关系数据库架构中，几乎不可能捕获具有一致状态的备份副本。基于此几乎不可能实现成功的数据恢复。究其原因，首先应该考虑到分布式架构的基本性质。此类架构旨在以尽可能短的停机时间扩展和抵抗节点故障。在备份分布式架构时，主要有以下挑战：数据写入可用节点。数据的最终落地点是不可预测的，因此数据无法在写入节点的同时被捕获。此后，数据在验证之前被复制到至少一个其他节点。这确保了高效的写入，同时还创建了数据的即时副本。然后将数据复制到更多节点以实现可用性。完成此操作后，可以快速连续更新相同的数据。这意味着同一数据在任何时候至少有3到4个副本。并且每个节点并不总是具有即时一致性。如果每套副本单独备份，效率显然是极低的。并且当任何节点发生故障时，其拓扑结构将立即发生变化。理论上，一个优秀的DevOps团队可以编写相应的脚本，保证数据库备份在80%到90%的时间内成功实现（但是，考虑到存在多节点故障、拓扑变化、数据库压缩等，脚本化非常困难）。不幸的是，备份本身只是议程中“较容易”的部分。事实上，恢复才是问题的关键。成功康复的机制比大多数人意识到的要复杂。它涉及以下具体过程：重建正确的拓扑结构。由于每个节点都是单独备份的，所以数据库必须恢复到备份时的拓扑状态（6节点到6节点，12节点到12节点），这必然涉及到跨云环境、测试/开发和持续集成/持续用例，例如交付。等待数据库修复和恢复。非关系数据库架构可以承受节点故障并保持正常运行，但这种具有数据协调功能的架构在恢复方面很差，尤其是与慢速存储驱动器配对时。重复数据删除导致多组不一致的版本。备份副本可能有三组或更多组所有数据副本处于不一致状态，因此需要先进行数据去重或一致性处理。数据历史并不总是可用的。在大多数分布式架构中，oplog以循环缓冲区的形式存在，在运行过程中会不断覆盖自己的内容。有时，我们甚至无法恢复必要的日志数据来实现数据库协调。没有可靠的方法可以返回到某个时间点。即使有了oplog数据，我们仍然很难重构出特定时间点的数据。在最好的情况下，您只会获得一组最新且相对准确的数据库副本。在现实世界中，即使数据能够恢复，整个周期也可能需要几天甚至几周的时间。但是最近发生的GitLab主库数据误删导致数据丢失的事故证明，即使是技术含量高的组织也很难顺利处理这个问题。如果没有可靠的备份和恢复过程，人为错误对数据库来说可能与自然灾害一样致命。【翻译稿件，合作网站转载请注明原译者和出处.com】
