谷歌數據中心都被雷劈了，你該如何做好「異地備份」？

家住北京西二旗的小張是一家互聯網金融公司的運維工程師，金融行業的數據可是很值錢的，任何的損壞和丟失都不能容忍。

為此，小張選了北京品質最高的機房，買了品質最好的硬體，做了全面的數據備份容災策略：

每 24 小時做一次全量備份，每 1 小時做一次快照備份，還有每 5 分鐘的增量備份。備份的數據存於專門的備份伺服器，在分散式系統中會有 3 拷貝冗餘，而且還考慮了跨機架的副本放置策略。每個環節都有監控和報警，系統運轉良好，各種故障都能及時鎖定及時處理。

但這樣，數據容災策略可以萬無一失么？

在一個炎炎夏日的傍晚，小張結束一天的工作，終於可以回家享受啤酒小龍蝦了。誰想天氣突變，狂風暴雨電閃雷鳴，小張電話響起：

機房被雷劈了！還被劈了三次！！！！

小張趕緊趕回去搶救，經過萬般努力，得以恢復大部分數據，但是仍有少量數據無法恢復，因為這部分數據的所有副本所在的硬碟損壞了 …

這個故事看上去不可思議，但是生活往往比真實更戲劇化，這種「被雷劈」的故事真實發生過，我身邊有人遇到過，連 Google 這種大公司也遇到過。

2015 年 8 月，Google 歐洲的數據中心 europe-west1-b 就遭遇了天災，被雷劈了！儘管 Google 的災備方案十分嚴密，但仍然有少量的數據永久丟失了。 Google 在官方的事故報告的最後給出了一段關於備份安全策略的建議，原文如下（鏈接：https://status.cloud.google.com/incident/compute/15056#5719570367119360）：

We would like to take this opportunity to highlight an important reminder for our customers: GCE instances and Persistent Disks within a zone exist in a single Google datacenter and are therefore unavoidably vulnerable to datacenter-scale disasters. Customers who need maximum availability should be prepared to switch their operations to another GCE zone.

大意是 Google 雲平台上一個區的計算實例和存儲盤存在單一數據中心風險，無法避免數據中心級別的災難。提醒客戶做好自己的異地備份，以保證最佳的數據安全。

除了雷劈這樣的自然災害，我們的系統每天都會面臨各種數據安全威脅，比如機房斷電、UPS 故障、被拔網線、系統被入侵、人為誤操作等等。

另一個更讓人扼腕的數據是，根據資訊安全機構 Ponemon Institute 調查研究，在發生重要數據丟失之後，僅有 6% 的公司能在缺乏災難恢復計劃的情況下倖存。

災難隨時都有可能發生，面對這個現實，能最大程度降低風險係數的，不是在災難發生後尋找解決方案，而是讓「重要數據永遠有備份」。

將重要數據備份到一個相對隔離的系統中（異地數據中心），是一個非常有效的備份方案，能規避上面提到的大部分風險，保障公司業務數據的安全。

如何做異地備份？

異地備份，顧名思義，就是把數據備份到物理隔離的另外一個地方。

在已有本地備份（同機房）的情況下，異地備份意味著要把數據完整地在其他地方再複製一份。根據主業務是自建機房還是使用公有雲的不同，異地備份在地點選擇上通常有下面幾種：

有兩個或以上的數據中心，數據可以在不同數據中心之間互備；

主業務系統在自己的（或者租用的）數據中心，備份數據在共有雲上；

主業務系統在公有雲上，備份一個副本在另一個服務區（ Region / Zone ）；

主業務系統在公有雲上，備份一個副本在另一家公有雲上。

自建多個數據中心並不多見，周期長、人力成本高。對於中小型公司，甚至大公司的部分非核心業務部門來說，目前的主流做法是選擇公有雲作為異地備份方案，因為它容易實施，能最快速保證數據安全。

那怎麼用公有雲來實施異地備份呢？

異地備份的理想與現實

在實施「異地備份」之前，一般會先做「本地備份」，即備份到同一個數據中心內，方便恢復。本地備份的存儲方案通常有以下這些：

自建分散式文件系統

優點：大多選用 HDFS 。它是 Hadoop 生態的默認存儲方案，有 3 副本冗餘的策略，還有機架感知特性，對大數據分析的支持也很友好。

缺點：HDFS 需要自己維護高可用的 Name Node 集群，容量規劃和擴容工作也會佔消耗運維團隊資源。如果你的 HDFS 集群還肩負業務計算和數據備份需求，基於 JVM 的 Name Node 在高負載工作下垃圾回收機制會造成存儲系統的卡頓。存在 HDFS 的數據計算時很方便，但是在數據恢復時就複雜了，要先把對應的數據通過 HDFS CLI 拷貝到本地才行，這對運維工程師來說來說是個噩夢。

自有機房中多機互備

優點：備份在本機文件系統上，可以使用全套的 Linux 工具集，文件備份、恢復都很方便。另外還能充分利用本地磁碟空間，極大的節約成本。

缺點：機器多了以後，所有備份不在一起，對於管理和恢復是個麻煩事。另外數據安全要依賴 RAID 方案，一旦 RAID 卡損壞，數據就有丟失風險。

公有雲上的雲硬碟、NAS

優點：這類存儲方案通常基於 NFS 協議訪問，如果某台機器需要恢複數據，可以直接掛載（要求在一個 VPC 內），省去了拷貝過程。

缺點：大多有單點問題，另外很多雲硬碟容量上限不大，如果你的數據量大，就需要頻繁創建新盤，管理很麻煩。

公有雲上的對象存儲

優點：存儲容量彈性擴展，按需付費，價格便宜，數據安全可靠。

缺點：存取都需要通過專用的 SDK 或 API ，沒有真正的目錄結構，不支持改名。很多系統不支持直接存取對象存儲，數據恢復時需要先下載到本地，當數據量很大時會耽誤緊急數據恢復的時間。另外，對象存儲缺乏各種一致性保證，會帶來難以預期的困擾。

公有雲 VM 上掛載本地磁碟（強烈不推薦）

虛擬主機上的本地磁碟不保證數據安全，在 VM 重啟、遷移時數據可能會丟失，通常是用來存儲臨時數據，強烈不建議用本地盤做備份。

總的來說，這 5 種「本地備份」方案本身各有優劣，在考慮到基於「本地備份」進行「異地備份」時候，方案 3 和方案 4 稍好，但是在實施「異地備份」時也各自的問題。方案 3 中，無論使用公有雲的 NFS 存儲還是基於雲硬碟自建 NFS，因為協議不支持傳輸加密，跨公網直接掛載很不安全，需要再搭配 VPN 或者其他網關來解決。方案 4 需要額外學習所選擇的公有雲的 API 和 SDK。如果要換雲平台，API 和 SDK 還得重新學一遍。

在設計異地備份方案時，還得考慮因備份的存儲位置不在同一個高速內網內時帶來的傳輸問題，傳輸會比較慢而且不穩定，還容易被竊聽。如果存儲系統不支持從公網直接訪問（比如 HDFS 和 NAS 等），還需要設計專線或者 VPN 來連通。

我們針對這個問題很多團隊的做過交流，只有少數團隊實施了異地備份。他們的實施辦法，大多是設定一個定期任務，使用 rsync 將本地備份的數據全量非同步複製到另外一個 POSIX 兼容的存儲系統中。

這種方式非常容易實施，但對存儲系統有一定的要求：

兼容 POSIX ，沒有額外的學習成本，方便緊急情況下做數據恢復；

配置簡單，維護簡單。工作中 99% 的時間，我們不需要和備份系統打交道，所以最理想的情況是不用維護又非常穩定可靠；

適用於多個公有雲 / 區域，不被某個雲綁定。可以根據業務的具體需求有更多的選擇；

最重要的是穩定、可靠、安全，價格便宜當然更加分了。

我們在設計 JuiceFS （ 官網地址：juicefs.io ）時，充分考慮到上了上面幾點，希望為異地備份提供更好的選擇。簡單來說，它既可以像雲硬碟一樣掛載到虛擬機上，又同時擁有對象存儲的彈性擴容和便宜的價格。方便實用，靈活且門檻低，價格對比同類其它方案，也相當有競爭力（以單機的雲硬碟的價格得到比 NAS 還好的服務）。

作者介紹

蘇銳，TGO 鯤鵬會會員，Juicedata , Inc 聯合創始人。2017 年聯合創始 JuiceFS 分散式 POSIX 存儲服務（ 官網地址：juicefs.io ），在 beta 版本階段就獲得十餘個中美兩地優秀互聯網企業客戶。

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