云計算為IT環境及其備份策略和執行帶來了技術轉變。依賴完善的本地備份規則和模式很方便，但存在風險。這些備份策略之所以流行，是因為它們有效地解決了本地環境中的關鍵問題。但是，無法保證將這些解決方案原封不動地照搬到云環境中仍然有意義、適用并且經濟高效。

讓我們來看看兩種廣泛使用的本地備份策略——“祖父-父-子”和“3-2-1”策略，并探討它們在公共云環境中是否還有意義。

“3-2-1”備份策略

備份領域中最著名的策略之一—— 3-2-1 模式由三個元素組成：

• 保留（至少）三份數據。
• 將備份存儲在（至少）兩種類型的備份介質上。
• 在異地保留（至少）一份副本。

架構師不應該簡單地將這種策略照搬到云設計之中，而是應該問問自己：這種模式規則為什么在本地環境中至關重要？工程師和架構師想要用它們實現什么目標？

老式備份概念與云功能

老式備份概念與云功能反映了這些內容：左列里列舉了模式的規則。中間列顯示的是導致這種模式規則產生的需求和要求。最后，最右邊一列對云時代很重要：它列舉了亞馬遜的AWS，谷歌的GCP或微軟的Azure等公共云的變化。

幾十年來，服務供應商和企業一直將自己的服務器安置在數據中心，這些數據中心的選址都經過了精挑細選。他們希望降低洪水或者山體滑坡之類環境危害的風險。而很多中小型公共或私人組織以及中小企業可能仍然會把服務器放在辦公樓的地下室里。

火災、地震或者卡車撞入建筑物——所有這些事件都可能毀壞整棟建筑物，包括服務器機房。這樣一來，推薦的“一個異地備份副本”就成了唯一的救星。但是在云時代，這種備份是否還有意義？

“現場”與“異地”的概念在云時代發生了變化，但有一個風險始終存在：無論你如何仔細地選址，也無論你多么認真地對待物理安全性，都可能有一架飛機撞上你選中的建筑物，或者一場大火（以及隨后的消防工作）依然可能摧毀數據中心。將生產工作負載放在一個數據中心并且至少在另一個數據中心有一個備份的做法仍然有意義。AWS跨區域復制（AWS Cross-Region Replication）或者Azure中的異地冗余存儲等功能甚至讓小型企業也能夠為區域性或者全國性的災難做好準備。

對“兩種類型的備份介質”規則的需求不太明顯。但是，讓我們回顧一下公司將備份存儲在磁帶或光盤上的時代，看看可能出現的問題。首先，為了方便起見，工程師可能會決定將所有備份保存在一個介質上。如果此介質有缺陷或丟失，所有備份就都丟失了。一個介質顯然風險太大，但是如果使用三個磁帶，每個磁帶都可以工作數年或者數十年，會有什么風險？

為了便于解釋，我們假定一年內丟失一個備份磁帶的概率為0.1%，并假設我們有三個備份。那么，丟失全部三個備份的可能性是0.1%*0.1%*0.1%=0.001%。如果覺得這個值太高，可以再增加三個備份。在一年之內丟失所有六個備份的概率是0.000001%。相比之下，你此生被閃電擊中的概率是0.0065%。考慮到這些可能性，你是否會投資降低同時丟失三個或者六個磁帶的風險呢？

這是一個棘手的問題，因為它建立在一個常見的錯誤之上：假設這些事件彼此不相關，但實際情況并非如此（統計中的因變量和自變量）。如果一盤磁帶因為材料缺陷損壞，同一家工廠的同一臺機器上生產的所有磁帶都可能具有相同的缺陷。因此，在本地環境中，要求使用兩種類型的備份介質是一種方便且易于實現的方法，可以降低所有介質同時損壞的風險。但是這條規則能怎么幫助云備份呢？

答案是：這很復雜。S3 對象存儲的持久性服務水平協議為一年內 99.9999999999%。但是，由于這是服務水平協議 （SLA），因此你必須信任服務提供商，并且無法驗證技術設計和實現。如果云供應商沒有兌現SLA，你的公司可能會破產，但云供應商可不會破產。云供應商可能會給你的云服務帳單打一點折，但是如果你的數據丟失了，這點折扣完全無濟于事。我個人的觀點是：“兩種介質”規則在云中幾乎是不可能實現的，但是如果你信任服務水平協議，這條規則也就沒有必要了。

“3-2-1”中的“3”指的是保留數據的三個版本；例如，在不同的時間點進行兩次備份。該策略的一個流行的變種超出了這些要求，這就是另一個眾所周知的備份策略：“祖父-父-子”模式。

了解“祖父-父-子”策略

此數據備份模式的典型實現：

• 每周進行一次備份（父）
• 執行每日備份（子）
• 每月保留一個備份（祖父）

祖父-父-子備份概念的月計劃示例

展示一個每周“父”備份、每月“祖父”備份以及每日“子備份”的計劃是個什么樣子。

“祖父-父-子”備份策略是一個復雜的概念，涵蓋了公司需要備份的各種場景。第一種情況關乎操作失誤。從理論上說，管理員永遠不會錯誤地刪除生產數據庫。

同樣，工程師在將測試系統配置更改應用于生產系統之前，應該仔細檢查。但是，如果現實偏離了理論，工程師們就必須將服務器和組件快速回滾到混亂發生之前的狀態，解決方案就是使用最近的更新——例如前一天的備份。“子”備份可以滿足這個要求。

如果勒索團伙或者政府資助的黑客滲透進入IT環境之中，可能在幾天或者幾周之內都不會被發現。因此，昨天的備份沒有多大幫助。相反，工程師們必須將配置和應用程序（不是業務數據）回滾到幾周之前滲透未發生時的狀態。在這種情況下，“祖父”備份是理想解決方案。

上面兩種示例方案對云環境也必不可少。不同之處在于云中新的數據備份功能，例如對象版本控制或者時間點恢復。

時間點恢復（PITR）在各種數據庫中已經存在了一段時間了，但是公共云加速了推廣并將其集成到企業備份策略之中。PITR 是一種時間旅行工具，允許管理員和工程師將數據庫狀態回滾到某時間段內（比如上周或者一個月內）的任何給定時間。如果可用并激活，PITR將讓每日備份和每周備份變得過時。根據特定云服務的具體要求、風險偏好和功能，企業在PITR 之外還需要“祖父”備份。

對象版本控制是另一個概念，對對象存儲特別有幫助。當用戶、腳本或者應用程序將對象替換為較新的版本時，云會將舊版本按照定義保留一段時間。在此期間，不需要進行額外的備份（例如每天或者每周），不過架構師可能還要額外配置長期備份。

高級云備份功能示例——Azure Cosmos DB（左）和 AWS S3（右）

傳統備份規則今天仍然適用

在云端配置備份前所未有地容易。只要點擊幾下，就完成了——然而，存儲的巨額賬單可能會毀掉你的業務案例。為了防止成本飆升，架構師在制定云備份策略的時候必須考慮成本效益關系。將每月備份保留一年意味著你有十二個備份。將每周備份保留一個月還會增加四個備份。然后，如果你嚴格執行每日備份并將其存儲一周，就還會增加七個備份。因此，備份存儲的體積是生產存儲的21倍。

既定的傳統備份規則（如“3-2-1”和“祖父-父-子”）在當今的云架構中仍然有意義。它們的意義更多地來自戰略背后的要求，而不是它們具體的規則和技術。然而，云也具有新的功能，包括冗余和云備份功能，這是大多數中小型公司幾年前做夢都想不到的。

因此，云工程師的任務不是照搬以前的模式。他們應該用今天的云功能來滿足以往要求中仍然有意義的部分。這樣，IT部門就可以定義并執行兼具成本效益和前瞻性的云備份策略。