敲黑板：雲伺服器備份關鍵技術大揭秘

我們知道，傳統的企業存儲系統中基本都包含快照功能，其作用主要是能夠進行在線數據備份與恢復。當傳統存儲（包括：文件，塊等）發生應用故障或者文件損壞時可以進行快速的數據恢復，將數據恢復某個可用的時間點的狀態。

快照的另一個作用是為存儲用戶提供了另外一個數據訪問通道，當原數據進行在線應用處理時，用戶可以訪問快照數據，還可以利用快照進行測試等工作。所有存儲系統，不論高中低端，只要應用於在線系統，那麼快照就成為一個不可或缺的功能。

華為作為擁有10餘年研發經驗的專業存儲廠商，把其企業數據備份的軟體能力進行了服務化，並且由華為雲推出了雲伺服器備份服務。

什麼是雲伺服器備份

雲伺服器備份（Cloud Server Backup Service，CSBS），可以為彈性雲伺服器（Elastic Cloud Server，ECS）提供備份服務，支持基於一致性組快照技術的多雲硬碟備份服務，並支持利用備份數據恢復彈性雲伺服器數據，最大限度保障用戶數據的安全性和正確性，確保業務安全。

簡而言之，就是在病毒入侵、人為誤刪除、軟硬體故障等場景下，通過雲伺服器備份能將數據恢復到備份的時間點。

要做到雲伺服器備份，首先必須要保證各個雲硬碟備份的一致性，這就涉及到一致性和一致性組。

一致性與一致性組

雲伺服器備份的「一致性」，是指在應用看來備份中的數據是同一時刻的，用該備份恢復後，應用能繼續正常運行。存儲領域通常將該一致性分為應用一致性（Application Consistency）和崩潰一致性（Crash Consistency）。

業界權威的觀點：

「

Application Consistency ：Consistent copies are created after applications are gracefully shut down, quiesced, or put in hot backup mode。

Crash Consistency：Creates point-in-time copy of storage that is usable with crash recovery applications，Creates crash consistent copies without coordinating with applications. However, write ordering is maintained for dependent writes in copies across volumes. It』s a logical dependency,not a time dependency.

」

英文很拗口？那我們就來通俗的說一說——

應用一致性，簡而言之就是打快照的時候業務不下IO。實現方法：

（1）凍結IO，刷緩存；

（2）對一組雲硬碟打快照；

（3）解凍IO。

崩潰一致性指系統崩潰（突然掉電或死機）時數據所處的一致性狀態，理論上任何應用都應該能處理突然掉電或死機的情況，即系統恢復後應用能根據崩潰時數據的狀態繼續業務或正常開始新業務。崩潰一致性對應用下IO的順序有時序上的要求，滿足崩潰一致性的備份要保證數據之間時序上的依賴關係不被破壞。雲伺服器備份滿足崩潰一致性的實現方法：打一致性組快照。

說到一致性組快照，要先介紹一下什麼是一致性組。典型的企業應用，譬如資料庫場景，數據往往分布在多個雲硬碟上，數據之間的依賴關係也在多個雲硬碟之間存在，這多個雲硬碟就組成了一致性組。

圖2.1 日誌盤與數據盤組成的一致性組

譬如，在圖2.1的例子中，應用必須等待寫日誌(IO1)完成才會去寫數據(IO2)，且必須等待寫數據(IO2)完成才會去刪日誌(IO3)，因此該Log disk與Data disk組成了一個簡單的崩潰一致性組。

為了使一致性組快照滿足崩潰一致性，底層存儲對各個雲硬碟創建出來的快照有時序上的要求。

下面我們來看創快照的時序正確的場景：

場景一：在t1?(T1,T2)時刻對Log disk打快照；在t2?(T1,T2)時刻對Data disk打快照

圖2.2 正確時序：一致性組快照中只能讀到IO1

如圖2.2所示， Snap_log中可以讀到IO1， Snap_data中不包含IO2。這種情況是從一致性組快照中只讀到了IO1，滿足時序。如果系統崩潰，我們可以將數據恢復到t2。

場景二：在t1?(T1,T2)時刻對Log disk打快照；在t3?(T2,T3)時刻對Data disk打快照

圖2.3 正確時序：一致性組快照中能讀到IO1和IO2

如圖2.3所示， Snap_log中可以讀到IO1，Snap_data中可以讀到IO2，這種情況是從一致性組快照中讀到了IO1和IO2，滿足時序。如果系統崩潰，我們可以將數據恢復到t3。

換言之，Log disk和Data disk打快照的時序需要滿足：在這兩個快照中，要麼三個IO都沒有，要麼只能讀到IO1，要麼能讀到IO1和IO2，要麼能讀到IO1、IO2和IO3，即這兩個快照對於這三個IO滿足時序依賴。

下面我們看一個錯誤的打快照的時序：

場景三：在t0?(0,T1)時刻對Log disk打快照；在t3?(T2,T3)時刻對Data disk打快照

圖2.4 錯誤時序：一致性組快照中不能讀到IO1可以讀到IO2

如圖2.4所示， Snap_log中讀不到IO1， Snap_data中可以讀到IO2，這種情況違背了IO1->IO2->IO3的時序依賴。假如寫IO2的過程中出錯，此時Snap_log中沒有對IO1的記錄，無法通過日誌正確恢複數據，造成數據丟失。

雲伺服器備份的具體實現

第2部分，我們介紹了應用一致性和崩潰一致性，對應這兩種不同的一致性，雲伺服器備份有兩種實現方式。

3.1雲伺服器備份實現應用一致性

圖3.1 雲伺服器備份實現應用一致性

（1） 開始進行雲伺服器備份

（2） 查詢虛擬機中的雲硬碟列表

（3） 後端存儲收到消息後，對虛擬機凍結IO，刷緩存

（4） 生產存儲創建快照

（5） 解凍IO

（6） 備份軟體將快照備份到「備份存儲」中

3.2雲伺服器備份實現崩潰一致性

圖3.2 雲伺服器備份實現崩潰一致性

對比圖3.1和圖3.2，可以看出實現崩潰一致性，對上層應用不可見，不需要凍結和解凍IO，但是要在生產存儲中打一致性快照，一致性組快照需要滿足時序依賴，詳見本文第2部分。

綜上，應用一致性備份間隔不能太短，否則應用需要頻繁刷數據，影響業務；崩潰一致性組快照則可以在1秒內完成且應用不感知。應用一致性與崩潰一致性各有其特點，上層可根據不同的應用場景靈活選擇。

Finally~

上文中我們詳細討論了雲伺服器備份的流程和一致性，由此我們得出一個概念，雲伺服器備份就是讓虛擬機裡面的「雲硬碟們」能夠happy地拍個「全家福」，通過這個「全家福」我們隨時可以感受到當年的幸福狀態（恢復到備份時的數據和狀態）。所以，現在你知道雲伺服器備份是什麼了吧。

就在本月，華為雲的雲伺服器備份服務開啟了「年中鉅惠-0元購」活動，買多少，送多少，詳情請識別下方二維碼了解！

GIF

點擊原文，了解更多雲伺服器相關信息！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！