讓 JuiceFS 幫你做好「異地備份」

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

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

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

但這樣，資料容災策略可以萬無一失麼？

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

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

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

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

**2015 年 8 月，Google 歐洲的資料中心 europe-west1-b 就遭遇了天災，被雷劈了！儘管 Google 的災備方案十分嚴密，但仍然有少量的資料永久丟失了。**Google 在官方的事故報告的最後給出了一段關於備份安全策略的建議，原文如下：

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% 的公司能在缺乏災難恢復計劃的情況下倖存。

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

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

如何做異地備份？

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

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

1. 有兩個或以上的資料中心，資料可以在不同資料中心之間互備；

2. 主業務系統在自己的（或者租用的）資料中心，備份資料在共有云上；

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

4. 主業務系統在公有云上，備份一個副本在另一家公有云上；

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

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

異地備份的理想與現實

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

1.自建分散式檔案系統；

• 優點：大多選用 HDFS。它是 Hadoop 生態的預設儲存方案，有 3 副本冗餘的策略，還有機架感知特性，對大資料分析的支援也很友好。
• 缺點：HDFS 需要自己維護高可用的 Name Node 叢集，容量規劃和擴容工作也會佔消耗運維團隊資源。如果你的 HDFS 叢集還肩負業務計算和資料備份需求，基於 JVM 的 Name Node 在高負載工作下垃圾回收機制會造成儲存系統的卡頓。存在 HDFS 的資料計算時很方便，但是在資料恢復時就複雜了，要先把對應的資料通過 HDFS CLI 拷貝到本地才行，這對運維工程師來說來說是個噩夢。

2.自有機房中多機互備：

• 優點：備份在本機檔案系統上，可以使用全套的 Linux 工具集，檔案備份、恢復都很方便。另外還能充分利用本地磁碟空間，極大的節約成本。
• 缺點：機器多了以後，所有備份不在一起，對於管理和恢復是個麻煩事。另外資料安全要依賴 RAID 方案，一旦 RAID 卡損壞，資料就有丟失風險。

3.公有云上的雲硬碟、NAS：

• 優點：這類儲存方案通常基於 NFS 協議訪問，如果某臺機器需要恢復資料，可以直接掛載（要求在一個 VPC 內），省去了拷貝過程。
• 缺點：大多有單點問題，另外很多雲硬碟容量上限不大，如果你的資料量大，就需要頻繁建立新盤，管理很麻煩。

4.公有云上的物件儲存：

• 優點：儲存容量彈性擴充套件，按需付費，價格便宜，資料安全可靠。
• 缺點：存取都需要通過專用的 SDK 或 API，沒有真正的目錄結構，不支援改名。很多系統不支援直接存取物件儲存，資料恢復時需要先下載到本地，當資料量很大時會耽誤緊急資料恢復的時間。另外，物件儲存缺乏各種一致性保證，會帶來難以預期的困擾。

5.公有云 VM 上掛載本地磁碟（強烈不推薦）：虛擬主機上的本地磁碟不保證資料安全，在 VM 重啟、遷移時資料可能會丟失，通常是用來儲存臨時資料，強烈不建議用本地盤做備份。

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

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

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

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

1. 相容 POSIX，沒有額外的學習成本，方便緊急情況下做資料恢復；
2. 配置簡單，維護簡單。工作中 99% 的時間，我們不需要和備份系統打交道，所以最理想的情況是不用維護又非常穩定可靠；
3. 適用於多個公有云/區域，不被某個雲繫結。可以根據業務的具體需求有更多的選擇；
4. 最重要的是穩定、可靠、安全，價格便宜當然更加分了；

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

如何用 JuiceFS 來做異地備份呢？

JuiceFS 是專為公有云而生的分散式 POSIX 檔案系統，它將資料儲存在你自己的公有云物件儲存中，通過由我們維護的強一致高效能的元資料服務變成一個 POSIX 相容的分散式檔案系統。

無論你的主業務在自建機房還是公有云上，都可以利用 JuiceFS 來做異地備份。參照 JuiceFS 使用指南將 JuiceFS 掛載到你主機房或者所用的公有云主機上，然後使用 rsync 等工具將備份資料直接寫入即可。JuiceFS 的傳輸都是加密的，並且會自動將大檔案分塊並行傳輸，即使通過不可靠的公網進行備份也可以獲得很好的效能和體驗。

如果你使用 JuiceFS 來直接儲存資料或者做本地備份，它還有個更厲害的功能支援你輕鬆完成異地備份：複製（Replication），它會自動將寫入的資料非同步複製到指定的另一個物件儲存中（可以是任意公有云和服務區）。假設你的主業務在 AWS 北京區，資料需要備份到 UCloud 廣州區，只需要建立一個在 AWS 北京區的檔案系統，再啟用複製功能（並選擇 UCloud 廣州區），所有寫入到 AWS S3 的資料（包括啟用複製功能前）都會被自動複製到 UCloud 廣州區的 UFile 中。當你需要在 UCloud 廣州區進行資料恢復時，它會直接從 UFile 讀取資料，速度快且不需要付流量費。

企業版 JuiceFS 的另一個大殺器是全球資料映象，它可以幫你實現超遠距離的近實時資料映象（只讀），比如從美國映象到中國，或者反過來。相比上面說的資料複製功能，資料映象還會建議元資料的只讀映象，以保證在超遠距離的映象資料也能獲得很好的效能。我們在測試中發現，從 AWS 美東區同步到騰訊雲上海區，元資料只有秒級延遲，絕大部分資料在 30 秒內完成同步，偶爾被某牆阻斷加密連線導致資料同步滯後，客戶端也會主動修復同步，保證資料的正確和一致訪問（訪問時會略慢）。目前資料映象功能只開放給企業客戶，感興趣的同學可以聯絡我們瞭解更多技術細節。

我們相信，JuiceFS 是目前市場上能找到的最好的資料備份方案，沒有之一，因為它：

1. 支援全球 13 個公有云平臺近 100 個服務區間自動複製，支援平臺還在陸續增加；
2. 保證資料一致性，和 99.95% 的高可用性；
3. 傳輸加密，企業版支援儲存加密；
4. 相容 POSIX，JuiceFS 可以通過 FUSE 掛載到 VM 上，使用體驗和本地磁碟一致；
5. Serverless，完全由我們和公有云維護，客戶無需維護；
6. 提供豐富的監控資料，可整合在客戶自己的監控系統中；
7. 複製（Replication）功能可幫你實現輕鬆的跨雲跨服務區備份或者遷移；
8. 回收站機制，有效防止誤刪除，可以自己設定回收站儲存時間；
9. 節省大量成本。綜合考慮人力和時間成本，比其他方案節省 50% 至 80%。

對了，如果你是 Linux 和 Mac 的個人使用者，JuiceFS 可以直接掛載到你自己的電腦上，上面的方法同樣適用於備份你的個人資料，我們還提供了1TiB 永久免費容量（物件儲存可能不是免費的）。

如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)