【51CTO.com快譯】云原生應用時代下，對備份體系進行調整無疑已經成為一種必然。然而，即使逐步淘汰了原有備份與負責處理相關任務的腳本，大家仍會發現各類下一代應用程序及數據庫（包括Apache Cassandra、MongoDB、Amazon DynamoDB、微軟DocumentDB、Apache HBase等等）在備份與恢復方面的表現令人沮喪。為什么會這樣？

[[185468]]

簡而言之：在任何擁有最終一致性特征的非關系數據庫架構當中，我們幾乎都不可能捕捉到具備一致性狀態的備份副本。而以此為基礎實現成功的數據恢復更是幾近不可能。

究其原因，首先應考慮到分布式架構的基本性質。此類架構旨在擴展并抵御節點故障，盡可能降低停機機率。而在對分布式架構進行備份時，主要存在以下幾項挑戰：

• 數據被寫入至某一可用節點。數據的***著陸點無法預測，因此無法在數據被寫入節點的同時對其進行捕捉。
• 此后，數據被復制到至少一個其它節點當中，而后方進行驗證。這確保了有效寫入，同時亦立即為數據創建副本。
• 接下來將數據復制到更多節點中以實現可用性。這一步完成后，同一數據可快速連續進行更新。
• 意味著任意時段同一數據都至少擁有3到4套副本。
• 且各節點始終不存在即時一致性。
• 如果對各套副本進行分別備份，則效率明顯極為低下。
• 而在任一節點發生故障時，其拓撲結構也將立即發生變化。

在理論上，出色的DevOps團隊能夠編寫對應腳本，確保在80%到90%的時段內成功實現數據庫備份（不過考慮到多節點故障、拓撲變更、數據庫壓縮等情況的存在，腳本編寫難度極大）。

然而遺憾的是，備份本身只是這一議程當中較“容易”的部分。事實上，恢復才是問題的關鍵所在。成功的恢復機制要比大多數人想象中的復雜得多。其涉及以下具體流程：

• 重構正確拓撲。由于各個節點皆單獨備份，因此數據庫必須恢復到與備份時對等的拓撲狀態（6節點對6節點，12節點對12節點），而其中必然涉及跨云環境、測試/開發與持續集成/持續交付等用例。
• 等待數據庫進行修復與恢復。非關系數據庫體系能夠承受節點故障并保持正常運行，然而這種具備數據協調能力的架構在恢復方面則表現糟糕，特別是在配合低速存儲驅動器的情況下。
• 重復數據刪除引發多套不一致版本。備份副本可能擁有三套甚至更多處于不一致狀態的全部數據副本，因此需要首先進行重復數據刪除或者一致化處理。
• 數據歷史并非始終可用。在大多數分布式架構當中，oplog都作為循環緩沖區存在，其會在運行當中不斷覆蓋自身內容。有時候，我們甚至無法恢復必要的日志數據以實現數據庫協調。
• 并不具備可靠的方法以返回某時間點。即使使用oplog數據，我們仍然很難重建特定時間點數據。在最理想的情況下，大家只會獲得一套時間點較近且相對精確的數據庫副本。

在現實世界當中，即使數據能夠得到恢復，整個周期也可能需要數天乃至數周。然而最近GitLab由于誤刪導致主數據庫數據丟失的事故證明，即使技術水平極高的組織機構也很難順利處理這一難題。而如果缺少可靠的備份與恢復流程，人為錯誤有可能與自然災害一樣對數據庫產生致命影響。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】