本周一，云頭條報道稱“Github.com 已掛了 8 個小時：數據存儲設備壞掉了!” 許多用戶在Twitter上紛紛吐槽，抱怨網站宕機，包括中國、日本的好多惴惴不安的程序員，一些人抱怨自己無法登錄進去，或者分支版本丟失了，等等。

　　乍一看，又是“宕機”惹的禍。可是，元芳，你怎么看?

　　疑點一：具體表現。

　　從美國西海岸時間周日下午4點開始，GitHub.com一直處于抽瘋的狀態。具體來說，該網站仍在提供頁面服務，它只是間歇性地提供過期的文件，但忽略了提交上去的Gist、代碼錯誤報告和帖子。有時候，它似乎在提供只讀緩存或它本身的舊備份，不過一些推送的新代碼無法發布到網站上。

　　官網故障

　　疑點二：官方聲明。

　　開發團隊在下午5點后說：“我們在繼續努力遷移數據存儲系統，以便恢復訪問GitHub.com的服務。”該團隊隨后在過去的幾分鐘補充道：“我們在繼續修復GitHub.com的數據存儲系統。在此過程中您可能會看到不一致的結果。”

　　官網聲明

　　一般來說，像上面案例中提到的“遷移數據存儲系統，以便恢復訪問GitHub.com的服務”，也是應對IT事故、恢復業務的常規流程，無可厚非。然而在故障8小時候，仍舊無法提供業務支持，只能提供“舊備份”數據或者“不一致”的數據，讓我不禁懷疑GitHub網站的數據有丟失的嫌疑。

　　作為一個面向開源及私有軟件項目的托管平臺，Github擁有超過900萬開發者用戶。在GitHub，用戶可以十分輕易地找到海量的開源代碼。這意味著每時每刻都有大量重要數據在GitHub匯集。如果真的丟失了部分數據，對GitHub來說可能只是一小丟丟，可是對最終用戶而言，則是100%的災難。

　　雖說容災備份領域早就突破了早期的“數據備份與恢復”范疇，而增加了“業務連續”方面的內容，但數據才是根本，沒有數據，談何業務?

　　在這一點上，我十分贊同容災備份老牌廠商和力記易提出的“一個優秀的容災備份方案，數據可用是底線”的說法。

　　2015年底，筆者在一次行業會議上結識了和力記易公司的張總。當時大會就數據安全的重要性進行熱烈討論，在交流時，有人提起前不久銀監會通報了某銀行的數據丟失問題，為什么明明做了“雙機雙柜”，怎么還是不能“幸免于難”?和力記易的張總寥寥數語解開了這個疑問，“數據庫數據還在，但是發生了內部邏輯錯誤(比如ASM頭文件錯誤)，所以整個數據庫就不可用了。”

　　我開玩笑的問張總“雙機雙柜方案都解決不了問題，你們和力記易的容災備份方案呢?”張總斬釘截鐵的說“我們可以!”

　　不論是何種數據備份，定時也好，實時也好，快照也好，鏡像也好，技術上的差別就決定了數據備份與恢復的不同結果。“備份數據”能忠實于“源數據”是最基本的，但是如果這份數據恢復回來以后無法使用，那這個恢復就沒有任何意義。和力記易容災備份軟件——備特佳的CDP持續數據保護技術，區別于市場其他備份軟件的最核心的一點就是：不僅能夠保證備份數據的完整性，更能保證恢復數據的可用性。這一點，和力記易稱之為“容災備份的底線”。

　　兩年前的經歷現在卻歷歷在目，當時是因為震撼，今天被Github勾想了起來，卻是衷心的希望GitHub的事故，乍一看是“宕機”，實際上也是“宕機”，千萬不要丟失數據，浪費了忠實用戶的心血和成績。

　　所幸，發文時，Github在歷經了24小時磨難后，終于恢復正常，數據沒有丟失，真好。