如何搞定 TB 級數據上云備份保護
大規模數據備份保護現狀
從多備份目前10萬多用戶中發掘的大型客戶看，業務規模稍微大一點，日志，DB歸檔，在線編輯，生產加工產生的數據，設計類文檔，及日常運營的累積的數據等就輕松超過TB級。而對于TB級數據，有幾種場景定義和區別：
- 單個節點的數據量上TB級
- 總量上TB級，但分布在多個節點
- 總量上TB，但單個文件量上百GB
- 總量上TB, 文件數規模很大，上萬千，甚至過億
- 總量上TB，類型不一樣，有的是DB備份后的壓縮文件，有的是圖片，有的是文檔類
TB級數據是用戶產生，從用戶中來，到用戶中去，比如視頻，圖片等UGC內容，對于這類冷的數據，逐步也需要進行歸檔冷備起來
對于目前以上6種情況，我們了解到，絕大部分企業，并沒有做比較系統的保護，或者說做了系統的保護，但都是在本地環境做的，一旦遇到人為原因，軟件缺陷，或 者存儲故障等，數據丟失的風險相當大; 有相當能力的，自己做了異地或自己做云存儲備份方案，但在靈活，系統化的，擴展性，成本方面并沒有優勢，畢竟對企業來說這不是核心運營的業務。
目前市面上的一些現有解決方案的特點：
策略一般就是全量+增量結合，選用專用的存儲設備，接上高速的光纖通道，配上專用的系統維護人員，這類方案在本地有足夠的優勢，備份和恢復快，但缺點也是相當的明顯，而且從設計理念上來看，以下的幾個點基本只有廠家自己革命才能解決：
第1：復雜，配置、部署以及使用操作維護都需要專業的管理人員，基本上在互聯網企業看，即使是做完B/C/D輪的，甚至IPO后的企業，出得起錢，也是不會考慮如此方案。
第2：升級擴展復雜，預先估計容量，后續擴展起來相當麻煩，必須的改變存儲策略，或重新離線做數據遷移分布。如果初始購買的存儲擴展有限，后期還不能很好的升級擴展。
第3：3-5年左右的生命周期，也就是說，數據經過幾年后，改造升級，購買新的方案是必須的，這樣當數據上到百TB級別，整個工程實施也是相當復雜了。
第4：難于對接互聯網+的思路轉換， 由于是離線的備份存儲方案，如果和業務系統對接，實際上基本上就是不太可能，尤其是目前不少企業開始加強互聯網+的運營思路的調整，數據不斷會和外部系統進行交換或對接。
第5：貴，特別的貴，如果對原始TB級數據做專業備份保護，投入得數十萬，具體到不同的行業，、性能和保護窗口參數稍微提升，投入立即上升到***。
當然如果對于非常有資源和有足夠多的預算，這一切都看起來都不是問題;而事實上，這類用戶還是只有在相當土豪的機構和企業里面才有，就連銀行都無法徹底按照嚴謹的實施和維護方案落實，才會出現接二連三的銀行機房燒毀數據丟失，或者宕機幾十個小時的情況。
終歸原因，對于關鍵的業務系統的備份保護，不緊緊是上了一套專業的方案，或者做了異地災備，事情就可以***解決;更重要的是，還得有操作簡單，容易驗證，應急性強的方案。
解決思路
多備份從2013年成立以來，一直以互聯網的簡單、親民的服務化思路演化，目前服務過的客戶，包括GB級的到TB級，涉及到關鍵運營業務系統數據庫，也包含 企業日常運營產生的文檔資料存儲備份保護等。經過上PB級的數據訓練，多備份從第1代全云的架構方案，到目前迭代的到***的第2代基于混合云架構的保護方 案。
第2代方案設計的目標主要面向TB級數據保護需求，徹底切分TB級數據6個構成面，并主要分解為如下幾個點：
- ***化降低備份存儲空間，數倍降低企業TCO投入
- 簡化使用門檻，包括配置流程，以及保護策略
- 數據備份和恢復的速度要在基于云的架構下，足夠的快
- 按需在線擴展，永不停機，足夠可靠
- 支持數據按需流動，真正意義讓數據在必要的時候，能動起來
- 僅由客戶全程加密掌控數據，充分保護數據隱私
- 基于以上6個設計目標，我們從幾個方面來剖析多備份是如何做到的
- 以云為核心，外網IT存儲設施混合的本地+云的混合設計模型
首先，多備份整體架構，圍繞云來設計，充分利用云的幾個特點
- 按需擴展，對客戶，對多備份自身服務的投入按需增加
- 可靠，云的計算和存儲分布特點，使得系統在計算和存儲都具備傳統結構不具備的數倍的可靠性
- 安全，基礎云服務商自身在安全方面不計成本，比起自己構建IT設施，來得更加專業
- 擴展，開放性更好，使得構建的服務，更容易外部系統對接
目前在具體的基礎實施平臺中，重點包括阿里云，騰訊云，AWS，金山云，微軟AZURE，移動云，七牛，百度云等平臺，這些都是全球或國內知名的大型云平臺。
其次，為了更好融合企業IT場景，以及一些合規規定，多備份在第1代云的基礎上，增加了外圍對接，支持數據備份存儲在本地環境的存儲設施，如NAS, SAN 或者節點的另外的磁盤分區等，這樣一來有3個好處：
- 數據可以在本地存儲一份，特別是熱一點的數據， 其他數據可以部分或者全部上云進行備份保護起來
- 常規的備份和恢復任務的會第1時間在本地環境完成，數據會在本地完成后，最快的時間同步上云
- 一些政企合規的數據可以保存在內部，其他的非敏感類的數據可以加密上云。
#p#
數據發現，傳輸，存儲等全部采用全增量+時間點版本映射結構設計
具備時間刻度特性的，本地和云兩級全增量索引
為了實現更低的存儲開銷，更快的備份和恢復速度，多備份從索引的設計，數據版本組織策略上都采用全增量模型，并且支持任意時間點的版本和索引的映射，這樣就為任一時間點的數據恢復或下載等提供了可行支持。
索引是構成整個系統的關鍵，數據的變化，無論從本地往云，還是從云往本地，都以來索引來快速找到對應的數據塊。而傳統的方案里面，索引也存在。多備份的特點 在于，結合了云以后，索引全部采用分區分段構建云索引中心的擴展模型，在量級，動態遷移是傳統的方案無法比較的。理論上，客戶越多，數據越大，邊際效應就 越好，給客戶回饋的成本優勢就更越明顯。
在這里，本地的索引用來快速支持數據的變化檢查，云端的索引用于本地失效后的變化檢測，以及在線數據服務接口的支持。
在每一次的數據備份時刻，都會記錄相應的數據映射關系，這樣可以滿足任意時間點的數據恢復和使用檢索需求。
按 照目前的設計，在本地可以支持2TB的數據索引關系，支持的數據量可以到達PB級，文檔(含數據庫備份壓縮備份歸檔數據文件)數量可以到達十億級別規模。 而在云上集中的存儲規模理論上受限于云平臺本身的存儲容量，幸運的是，即使在這一刻，多備份也可以正常運行，原因在于，多備份底層已經支持多個云的分布或 聚合。
本地+云兩級全增量策略保護模型，更快，更省的本性
多備份在數據策略化組織這里全部采用增量模型，與傳統的定期全量+增量模型在存儲空間和效率方面有著顯著的區別。一般原始數據在500GB規模的，按照通常的服務溝通模型下來，3個月下來也得有10TB級規模了，如果采用傳統的方案，成本將到達***投入規模。
多備份依托于云存儲的冗余分布特性，在時間和空間分布的可靠性方面已經遠遠大于本地存儲。正因為如此，多備份的增量備份存儲策略機制在保持最小的數據開銷規模下，每次的備份效率都出奇的高，同樣，按照時間點任意恢復數據的時候速度也相當快。
同樣，由于其邊掃描邊備份，實時增量檢測，塊級存儲的增量特性，以及壓縮策略智能化，單個幾百GB規模的文件，文本和圖片視頻，還是在數量眾多的***規模下都可以勝任。
基于云的兩級增量模型***的好處就是在TB級數據規模下，具備超低投入，甚至低至傳統方案的1/10 TCO，高速度;同樣，具備時間刻度恢復的特點、
端到端AES256加密機制，與Cloud 5分塊算術冗余分布機制，讓數據足夠的安全與可靠
在多備份的整個體系設計中，安全是從端到后臺，整體設計全程考慮，不打折扣，嚴格從機制上保證數據上云的機密性。
數據從客戶端接入數據后，立即進行AES256加密，加密后的數據分布在云存儲中，而加密用的密鑰則是在安裝過程中，由客戶端產生并有客戶自己保存下來。對 于特別要求可靠的數據，Cloud 5技術可以在保持2倍的成本投入下，進一步在多個不同種類的云存儲，或者單個云的多個存儲中心之間提高備份數據可靠性，幾乎就是永不丟失。
圍繞80%的場景設計, 安裝設置與維護盡可能快和簡單
多備份在具體的部署方案上，分成控制中心和客戶端設計，當然還有無安裝模型。目前無論是控制中心，還是客戶端都采用80/20場景適應的原則來考慮，在具體 使用流程和參數布局上，全面改變傳統的幾百個令人發暈的參數配置方案。所有的標準化操作考慮80%的場景覆蓋，除了頻率，內容設置，速度限制，必要的鏈接 參數外，其他都不在多備份主流程中。這樣在具體的功能組合，流程模板顯示，操作菜單，以及按鈕都可以保持非常簡單的流程和交互設計。
作者介紹：
聯合創始人& CTO - 陳元強 曾就職于寶德、騰訊、盛大(旅游)、宜搜、4399，歷任經理、總監等核心研發崗位。主導過***IT安全系統研發和實施;負責家庭戰略項目的產品研發管 理工作，主導QQ空間大數據分析和騰訊網分布式流量分析平臺的研發。在海量用戶、數據安全、網絡通訊和大數據挖掘等應用領域方面具有豐富的經驗。
