在雲時代重新思考傳統的備份政策

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

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

“3-2-1”備份政策

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

• 保留（至少）三份資料。
• 将備份存儲在（至少）兩種類型的備份媒體上。
• 在異地保留（至少）一份副本。

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

老式備份概念與雲功能

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

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

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

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

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

為了便于解釋，我們假定一年内丢失一個備份錄音帶的機率為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部門就可以定義并執行兼具成本效益和前瞻性的雲備份政策。