在除夕的24：00，還有許多家人沒有回家，大家相約拍下各自的笑臉製作成一張全家福：
大表哥：親們，來，我們準備拍照啦！
海南度蜜月的表姐：茄子！
留學美國的堂弟：茄子！
還在工作崗位上的碼農表哥：茄子！
……
最後所有的照片拼在一起，一家人保持一個表情和口型，氣勢還是很完美的！
發揮一下想象力，如果每一個家庭是一臺服務器，每一個家人都是一塊雲硬盤，每個人給自己拍的照片都是一個快照，最後所有照片拼在一起就定格了除夕24:00點全家人的笑臉，咦~~這個全家福聽起來怎麼很像存儲技術中的整機備份？
1. 什麼是整機備份
整機備份又稱雲服務器備份（Cloud Server Backup Service，CSBS），可以爲彈性雲服務器（Elastic Cloud Server，ECS）提供備份服務，支持基於一致性組快照技術的多雲硬盤備份服務，並支持利用備份數據恢復彈性雲服務器數據，最大限度保障用戶數據的安全性和正確性，確保業務安全。
簡而言之，就是在病毒***、人爲誤刪除、軟硬件故障等場景下，通過整機備份能將數據恢復到備份的時間點。
要做到整機備份，首先必須要保證各個雲硬盤備份的一致性，這就涉及到一致性和一致性組。
2. 一致性與一致性組
整機備份的“一致性”，是指在應用看來備份中的數據是同一時刻的，用該備份恢復後，應用能繼續正常運行。存儲領域通常將該一致性分爲應用一致性（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，刷緩存（hold住情緒，把之前的表情從臉上刷走、保持微笑）；（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的記錄，無法通過日誌正確恢復數據，造成數據丟失。
3、整機備份的具體實現
第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地拍個“全家福”，通過這個“全家福”我們隨時可以感受到當年的幸福狀態（恢復到備份時的數據和狀態）。所以，現在你知道整機備份是什麼了嗎？哈哈，是的，整機備份就是一家人要整整齊齊~~在此給大家拜個晚年，祝大家新年快樂！
更多雲存儲技術乾貨請至華爲雲硬盤社區