企業業務稍微上點規模的，IT系統產生的資料很容易就超過TB級，並且資料文件等很容易超過億級別的規模，如果用手動複製的方案來備份，基本是非常困難的；這種情況下，即使購買一些專業系統，隨著資料量日益增大，跑起來也非常吃力。本文重點討論如何基於雲平臺，來實現對應的解決方案。
TB級海量檔案場景特點
- 檔案規模大，動作上千萬級規模
- 檔案目錄結構多，層次多
- 檔案大小從KB 到MB，GB，甚至百GB級別分佈
- 檔案變化快，或者有批量增加的場景
- 無用的，有用的，混在一起
- 時間分佈久，跨度大
- 檔案型別文字，視訊，圖片，壓縮等都有
- 單個節點的資料量上TB級
- 總量上TB級，但分佈在多個節點
面對如此特點，如果按照目前的裝置+軟體方案，在以下幾點有非常大的缺陷：
1.升級擴充套件複雜，預先估計容量，後續擴充套件起來相當麻煩，必須的改變儲存策略，或重新離線做資料遷移分佈。如果初始購買的儲存擴充套件有限，後期還不能很好的升級擴充套件。
2.3-5年左右的生命週期，也就是說，資料經過幾年後，改造升級，購買新的方案是必須的，這樣當資料上到百TB級別，整個工程實施也是相當複雜了。
3. 一次投入特別的貴，如果對原始TB級資料做專業備份保護，投入得數十萬，具體到不同的行業，效能和保護視窗引數稍微提升，投入立即上升到百萬級。
隨著資料量的增長，超過一個量級，比如10TB級別，其實這類方案已經難於勝任了。
破解思路
基本上來說，要破解海量數量，以及TB級增長的難題，基於雲的方案是目前最有前途的思路，雲有4個核心好處：
1.儲存和計算能力按需擴充套件
2.可靠，雲的計算和儲存分佈特點，使得系統在計算和儲存都具備傳統結構不具備的數倍的可靠性
3.安全，基礎雲服務商自身在安全方面不計成本，比起自己構建IT設施，來得更加專業
4.擴充套件，開放性更好，使得構建的服務，更容易外部系統對接
目前在國內以及全球其他地區，都有成熟的雲平臺可以作為構建基礎。當然，除了明顯的優點外，也有1個缺點是，雲畢竟在異地，速度方面沒有本地來得快，所以在設計系統的時候，要充分考慮到此處特點。以此為基礎，考慮構思如下備份系統的設計目標：
- 最高價效比的TB級海量小檔案備份服務
- 支援分散式，多節點集中管理監控
- 備份容易且快速恢復
結合雲平臺的優缺點，基本的設計思路大體如下：
- 規模上量：單點TB突破，分散式上量
- 最小空間佔用：最大化變小資料
- 平衡效能開銷：IO掃描和效益平衡
- 不做無用功：特徵型別自適應處理
- 最近最快，最遠最可靠：多級模式結合，平衡速度和可靠性
以下將圍繞以上5個點展開，看一個專業級別的備份保護系統如何打造。
TB級突破
實現TB級突破，重點思路在於如何解決備份和恢復的速度，以及海量規模的資料塊儲存。而解決資料備份和恢復速度的關鍵在於組織好資料索引；我們日常看到的網盤備份是簡單的同步模型，很難勝任連續的資料塊版本影射關係。而一個專業的備份系統，此處是必須要解決好。
架構上要突破純雲的方案，本地和雲結合
純雲的方案，用了雲的幾個優勢點，但也同時受雲天生異地的特點影響，在傳輸效率方面是必定落後本地的方案，在強調速度的備份和恢復場景下，只有壓縮資料，加大頻寬。因此，更好的專業級方案是兼顧雲和本地的優勢進行設計。
以下黃色部分，就是加的一層本地儲存；本地客戶端將以分塊的形式把資料寫入本地客戶端，同時啟動同步邏輯，把資料從本地同步到雲端儲存。
TB級資料重點在索引管理上要下功夫，索引分為本地和雲端兩級
本地索引採用分段分佈設計，突破傳統RDB單庫數量過大，查詢過慢的瓶頸。本地索引模型讀寫相對簡單，可以採用自己研發或開源的本地資料儲存方案，Sparkey, levelDB，BDB，甚至MongoDB等都可以，實現索引庫理論支援TB級以上的的索引大小，具體到檔案為每條索引可做到100位元組以內
索引容量： TB/0.1KB > 100億條索引
按照簡單的順序存取模型，海量的目錄，檔案索引，這種分級模型的索引框架，可以輕鬆解決TB級資料與海量小檔案場景的管理。
當然，如果離開了異地配合，這種方案還是不完整的。因此在雲上，要支援更大規模的索引容器。幸運的是，在雲上，我們可以選擇的方案還比較多。可以基於MongoDB，LevelDB等優秀的列模型資料庫，也可以基於雲平臺本身的分散式KV資料庫來儲存索引。
裝置通過排程中心定位到雲索引中心 ； 單個雲索引中心採用NO-SQL DB分散式設計，具體按照任務ID進行分佈。關於具體的索引容器，可以選擇雲平臺提供的KV資料庫，如果要更多靈活的控制，也可以自己選用專業的KV 資料庫來構建。理論上雲端可以管理索引的數量無限。
資料按系列段分塊儲存，提升混合雲模型的速度引數
普通的量級資料讀寫，無所謂要不要分塊了，但一旦規模上到TB級別，特別在檔案量變化快的場景，要儘可能縮短備份視窗，必要的資料儲存組織就顯得非常的關鍵。其資料儲存分為兩部分，本地和雲。
本地資料儲存設計，可採用N *KB – N *MB 相對固定系列段的分塊設計，兼顧讀寫效率與空間平衡分塊採用期望分塊方案，儘可能讓分塊分佈在1個區間，保證去重效果的同時，減低分塊對索引記錄數佔用的數量。本文按照64KB 到 4MB的經驗值方案來計算.
總可索引資料量區間：理論最小管理資料 100億* 64KB = 600+TB ， 理論最大管理資料 100億* 4MB = 40+ PB 這麼大的規模，理論上已經遠遠滿足資料儲存管理需要。
對於資料上雲，初始化系統這裡可以把裝置定位到不同的雲資料中心，與索引位於同1箇中心內；上傳的資料非同步化儲存到雲端儲存，或可同時非同步到特定的塊儲存裝置；對於塊儲存，提供合併機制，將小塊進行合併儲存，提高儲存讀寫效率。所以，理論上雲端冗餘管理的資料量受限於雲端儲存空間提供商的。
本地和雲的資料儲存組織方案，在本地通過相對分塊序列的方案，在雲採用雲端儲存的方案，從KB-MB級的小資料塊檔案都可以輕鬆管理起來。
上圖是基於索引和塊儲存結合的增量應用。任何一個資料塊的變化都會第一時間，通過本地的索引塊簽名快速判斷是否需要上傳備份 ； 如果本地的索引無法啟動，將從雲端獲取簽名進行比對。任何一個需要備份的資料塊，可以快速通過分塊序列儲存方案，儲存在對應的資料塊檔案中。
通過並行冗餘通道，提升上下雲的速度、穩定和可靠性
網際網路絡本身是一個質量無法端到端保證的的一個網路，傳輸的穩定性會又多個環節影響。包括運營商網路，平臺的網路，以及使用者接入的網路等。對於一個專業級的備份系統，必須要考慮網路通道的連續、穩定執行。
以上，在任何一次客戶端註冊期間，一旦認證通過後，可以根據系統資源情況，分配合適的資料節點給客戶端。 客戶端可以根據情況，正常情況下，多通道並行傳送 ； 一旦檢測到通道出現問題，自動摘除 ；各個節點會上報資料到排程中心； 同時當鏈路恢復的時候，自動接入到系統中。下圖就是示意多通道在同步到雲，以及從雲恢復或下載資料。
採用端到端加密資料塊設計，結合資料塊垮雲分佈機制，可靠儲存備份到本地和雲的資料
在備份體系中，資料保密性設計不依賴於人，從機制上保證資料備份到雲是機密的。最常用的一種方案就是採用對稱加密，具體可以採用AES，3DES等演算法。目前比較常用AES256位，而key的產生可以在客戶端產生。Key一旦丟失，資料將無法恢復和使用。因此key的妥善保護，也是非常重要。
在基於塊的加密設計中，結合雲分佈特徵，資料被打散在不同的儲存位置，因此在資料安全方面進一步增加了強度。基於目前的公有云平臺的情況，在國內和國外都有幾大主流的雲端儲存平臺，分佈在全球。理論上，資料可以分步在任何一個地方。唯一考慮的是資料如何跨地區進行同步和分佈； 當然這裡可以先寫入本地雲中心，冗餘塊通過高速通道，再同步其他雲中心，這裡可以是同構的雲，也可以是異構的雲。
引入自動適應方案，提升海量檔案和應用場景的適應能力
在海量檔案情況下，由幾種系統因素影響備份的效率和資源開銷。備份系統如果全速開進，會消耗過多的計算和IO資源，如果是生產系統，勢必也會帶來衝突。以下是幾種典型的需要規避的：
- 壓縮比例和CPU消耗的衝突
- 磁碟IO和小檔案隨機分佈的衝突
- 強加密和CPU需求的衝突
- 實時檢測和系統資源的衝突
- 檔案型別和壓縮效果的衝突
- 備份頻寬消耗
通過對頻寬，壓縮演算法，檔案型別定義等預定義策略，可以快速平衡好系統資源。這種適合在確定判斷系統場景的情況啟用。
對於無法預知的情況，啟動自動監測機制，包括壓縮比，是否硬體加密加速，是否需要啟動實時或批量掃描等。
總結與展望：
隨著雲平臺的成熟和發展，網路基礎設施日益完善，用雲構建的資料備份系統，可以充分利用天然的地區分佈，運維簡單，靈活擴充套件特點，以及彈性按需投入的優勢，企業資料走向雲端簡單更加簡單可行。