雲HBase釋出備份恢複功能，為使用者資料保駕護航。對大多數公司來說資料的安全性以及可靠性是非常重要的，如何保障資料的安全以及資料的可靠是大多數資料庫必須考慮的。2016 IDC的報告表示資料的備份（data-protection）和資料恢複（retention）是Nosql的最基礎的需求之一。
為什麼需要雲HBase備份恢複？
我們希望雲HBase支援備份和恢複功能，主要原因：
- 使用者直接通路操作資料庫，可能存在安全風險；
- 項目存在合規以及監管的強需求；
- 對資料庫恢複資料到任意時間點（歸檔到任意時間點）需求；
- HBase社群至今沒有release備份恢複功能。
1、使用者直接通路資料庫，存在安全風險
使用者通過接口直接通路HBase資料庫，這種情況下存在安全隐患的機率會比較大。一種可能性是黑客會通過黑客技術入侵資料庫，對使用者的資料進行肆意的“操作”，造成使用者資料無法通路，然後進行勒索，參考前段時間的某某某資料庫勒索事件。當然這種case 在阿裡雲相關資料庫上是不會發生的，我們的資料庫有一些安全機制進行守護，且雲HBase自己也有自己的安全機制進行保障。
另外一種潛在的安全隐患就是：由于使用者自己的誤操作造成的資料丢失或者資料庫不可通路，比如我們之前經常聽到的“某某DBA由于誤操作，造成資料庫資料被實體删除，無法恢複，造成公司損失”等等等消息。
上述兩種情況如果資料有備份的話，可以把備份的資料恢複回來，即可避免以上風險。
2、合規以及監管需求
這種情況主要存在于一些特殊的項目中。由于資料的重要性或其他原因，會有監管的部門對資料是否做備份進行合規檢查。比如我們曾經遇到的汽車行業的某公司，因為其每輛汽車資料的重要性，需要對這些車輛資料做實時備份，且這些資料如果存在大面積丢失則會直接帶來監管審查問題。對于這種有監管需求的項目，備份恢複是必不可少的。
3、資料庫恢複到任意時間點需求
對資料庫的資料歸檔到過去某一時間點也是對備份恢複的一個比較強烈的需求。假如測試腳本意外寫入生産環境下的雲HBase表中，那麼會造成很多無效的資料産生，對于這種過去一段時間存在無效資料，不僅占用存儲空間且不友善删除的情況，使用資料庫的PITR能力可以将資料庫資料做一種“清洗”，将資料恢複到産生無效資料之前。這裡需要說一下，雲HBase的恢複暫時隻能支援恢複到過去10天内的時間點，且時間點的精确度是小時級别，暫時不能很精确的細化。
4、HBase社群至今沒有release備份恢複功能
HBase社群官方到現在沒有對外釋出過穩定的備份恢複功能，官方建議的備份操作的方式在生産環境是不适合執行的。是以雲HBase提供一個穩定的備份恢複功能彌補了HBase社群在該方面的欠缺，也為廣大HBase使用者提供了一個選擇。
雲HBase備份恢複：賦能HBase備份恢複能力
雲HBase備份恢複的設計之初的目的就是：賦能雲HBase備份恢複的能力、百T級别(起)資料量備份恢複支援、低使用者使用門檻、高性能、低備份成本、支援冷熱分離、相容HBase2.0/1.x、備份集備份、恢複以及增量備份、時間點恢複等。
傳統資料庫備份恢複的能力都是TB級别，在交易等場景下面是足夠的，但面向大資料場景就捉襟見肘了。雲HBase通過垂直整合高壓縮、核心級優化等能力，将備份恢複的量級成功推高百倍以上，做到 百TB級别甚至更高 ，讓客戶在大資料量場景下也無後顧之憂。
我們最終給出如下架構：一種包含了全量（備份集）備份、全量（備份集）恢複、增量（實時）備份、增量（時間點）恢複幾個子產品，接下來就這幾個子產品進行介紹；
備份資料
備份資料分為2部分：開啟備份動作時間點前的存量資料，通過Hfile的形式進行讀取以及備份到目的端；時間點以及以後寫入的實時資料，會以Hlog的形式被讀取以及備份到遠端。這裡備份的遠端預設選擇是OSS，因為其具有11個9的資料可靠性，以及低成本等特點。上述存量資料的備份（備份集備份）會周期性的觸發，暫定周期是一周；實時産生的資料（實時備份）會及時的備份到遠端OSS。OSS上的資料，我們會相應保留2個周期，這樣做主要是為了清理備援資料。
備份資料過程中，通過調整流量控制，可以将備份帶來的影響降低到極低的一個程度。無論是備份集備份還是實時備份，通過failover、takeover等機制，可以保證即使某些備份程序異常，資料依舊可以被備份到遠端，這裡可以承諾做到小時級别的備份精确度。此外備份過程中，通過将備份資料備份流量均勻分攤到叢集中的各個機器，可以保證最高的備份效率，通過分布式的備份進而支援備份規模達到百T甚至更進階别，即隻要你敢存，我們就敢備份。
恢複資料
從産品層面來看，如果使用者執行恢複叢集操作的話，雲HBase會将資料恢複到一個全新的叢集。這麼做的目的是，盡可能的保證不侵入使用者資料，守護最後一道資料底線，如果資料恢複完成，對于原的叢集，使用者可以自行處理。
資料恢複主要是将使用者的資料，從遠端(預設OSS)進行下載下傳，其中包括存量的Hfile 資料以及增量的Hlog資料兩部分。那麼存量的Hfile資料，通過各個機器均衡下載下傳，并各個機器執行bulkload，保證較快速的将存量資料恢複。對于Hlog 資料，同樣做到分布式下載下傳，各個機器回放相關的Hlog。通過充分利用各個機器的資源，将恢複速度做到最優。
恢複支援備份集恢複以及時間點恢複，如果使用者想恢複到過去某一個具體時間段的資料，那麼在頁面選擇一下相應時間段，點選恢複即可。
一些名額
經過我們的理論分析以及實際測試（8C32G，8Tx10），給出下列資料名額：
1. 備份資料量可以達到百T級别甚至更高；
2. 備份集備份最長4天，正常情況遠小于4天；
3. 備份集恢複最長1天半；
4. 日志恢複資料精确度：1hour，最長容忍一小時的資料不準确；
上述第4點解釋下：所謂的恢複精确度是如果使用者想要将資料恢複到最新的一個時間點，恢複到的資料存在與需求的最新時間點資料最多一小時的誤差，其他的恢複是沒問題的，但是實際我們測試的情況遠小于這個時間。
由于分布式備份，同等資料量下備份以及恢複速度是傳統資料庫的數倍。備份資料量、備份/恢複速度會随着機器數量的擴容而不斷的增大。舉個例子同樣備份2T資料，傳統資料庫如果需要24小時，那麼我們可以保證備份速度可以保證小于等于12小時。
雲HBase和自建的差別
HBase社群到目前為止沒有release備份恢複功能，官網隻介紹了如果要做備份需要的操作流程參考
link，可以通過export做備份；此外社群有一個分支包含備份恢複功能，見
，但該分支開發好幾年，release時間未知，且版本不穩定；在這裡大概列一下雲HBase備份恢複和自建的差別；
| 雲HBase | 自建HBase | |
|---|---|---|
| 備份恢複操作 | 操作簡單，點選按鈕即可 | 操作複雜，需要手工觸發指令執行 |
| 備份過程是否依賴别的元件 | 依賴産品化元件，但是使用者無感覺，無需使用者操作 | 依賴MapReduce，需要使用者搭建或者部署 |
| 最長備份精确度時間保證 | 1小時 | 不确定 |
| 是否保證備份程序異常情況下的資料備份 | 有 | 沒有 |
| 穩定性 | 多種資料量下反複測試，保證穩定性 | 社群方案，穩定性未知 |
| 流量控制 | export方案無、分支未release方案有 | |
| 備份目的端資料備援 | 會有一定少量備援資料 | 存在較多備援資料 |
| 備份時間保證 | 有最長時間保證 | 未知 |
如何進行備份以及恢複
備份恢複整個操作流程都是非常簡單的界面化操作，一路點點點既可以完成整個操作。
執行備份
使用者購買完成雲HBase叢集以後在自己的控制台左側欄會看到“備份與恢複”選項欄，選擇該欄目，然後出現備份恢複相關的選項，第一次執行備份會需要重新開機叢集，建議使用者在一個低峰期進行開啟操作，開啟備份操作可能需要幾分鐘，請使用者耐心等待。點選開啟備份恢複以後，按照對應的選項指導 使用者可以選擇備份集備份的時間點，選擇完成以後，就會周期性的在這個時刻觸發一次備份集備份，至于實時資料備份在第一次開啟備份的時候就觸發了。
完成上述設定以後，我們整個備份操作即可正常開啟以及執行了。
執行恢複
雲HBase的恢複包括備份集恢複以及時間點恢複。備份集恢複即恢複到過去執行的某一次備份集備份的資料，而時間點恢複即使用者可以選擇某一個特定的時間段（小時級别），然後雲HBase的恢複程式即可将資料恢複到對應的時間點。無論是備份集恢複還是時間點恢複都是将資料恢複到一個新的叢集。
選擇是備份集恢複還是時間點恢複主要是在控制台頁面選擇：
上述頁面可以選擇”備份點建立實列“，最後可以在下述頁面選擇具體的備份情況：
完成如上操作以後，恢複程式開始執行恢複，等資料恢複完成即可。
展望
後期我們的備份恢複會進一步深耕，繼續做的更細緻，由于現階段我們的備份恢複隻能達到叢集級别的備份，那麼接下來需要支援更細粒度的備份和恢複，暫定細化到表級别；此外，我們還希望備份恢複的精确度可以降低到秒級别，這個事情也是需要投入精力的；再次對應備份恢複的速度我們希望可以再進行優化。
産品入口：
連結：
https://cn.aliyun.com/product/hbase
雲HBase備份恢複使用文檔
https://help.aliyun.com/document_detail/68358.html?spm=a2c4g.11174283.6.585.5f113c2epivA3S