賦能雲HBase備份恢復 百T級別資料量備份恢復支援

  雲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備份恢復功能，官網只介紹瞭如果要做備份需要的操作流程參考 ，可以透過export做備份；此外社群有一個分支包含備份恢復功能，見 ，但該分支開發好幾年，release時間未知，且版本不穩定；在這裡大概列一下雲HBase備份恢復和自建的區別；

	雲HBase	自建HBase
備份恢復操作	操作簡單，點選按鈕即可	操作複雜，需要手工觸發命令執行
備份過程是否依賴別的元件	依賴產品化元件，但是使用者無感知，無需使用者操作	依賴MapReduce，需要使用者搭建或者部署
最長備份精確度時間保證	1小時	不確定
是否保證備份程式異常情況下的資料備份	有	沒有
穩定性	多種資料量下反覆測試，保證穩定性	社群方案，穩定性未知
流量控制	有	export方案無、分支未release方案有
備份目的端資料冗餘	會有一定少量冗餘資料	存在較多冗餘資料
備份時間保證	有最長時間保證	未知

如何進行備份以及恢復

---

  備份恢復整個操作流程都是非常簡單的介面化操作，一路 點點點 既可以完成整個操作。

執行備份

    

  使用者購買完成雲HBase叢集以後在自己的控制檯左側欄會看到“備份與恢復”選項欄，選擇該欄目，然後出現備份恢復相關的選項，第一次執行備份會需要重啟叢集，建議使用者在一個低峰期進行開啟操作，開啟備份操作可能需要幾分鐘，請使用者耐心等待。點選開啟備份恢復以後，按照對應的選項指導 使用者可以選擇備份集備份的時間點，選擇完成以後，就會週期性的在這個時刻觸發一次備份集備份，至於實時資料備份在第一次開啟備份的時候就觸發了。

    

  完成上述設定以後，我們整個備份操作即可正常開啟以及執行了。

執行恢復

  雲HBase的恢復包括備份集恢復以及時間點恢復。備份集恢復即恢復到過去執行的某一次備份集備份的資料，而時間點恢復即使用者可以選擇某一個特定的時間段（小時級別），然後雲HBase的恢復程式即可將資料恢復到對應的時間點。無論是備份集恢復還是時間點恢復都是將資料恢復到一個新的叢集。

  選擇是備份集恢復還是時間點恢復主要是在控制檯頁面選擇：

    

  上述頁面可以選擇”備份點建立實列“，最後可以在下述頁面選擇具體的備份情況：

    

  完成如上操作以後，恢復程式開始執行恢復，等資料恢復完成即可。

展望

---

  後期我們的備份恢復會進一步深耕，繼續做的更細緻，由於現階段我們的備份恢復只能達到叢集級別的備份，那麼接下來需要支援更細粒度的備份和恢復，暫定細化到表級別；此外，我們還希望備份恢復的精確度可以降低到秒級別，這個事情也是需要投入精力的；再次對應備份恢復的速度我們希望可以再進行最佳化。

產品入口 ：
  連結：

雲HBase備份恢復使用文件
  連結： https://help.aliyun.com/document_detail/68358.html?spm=a2c4g.11174283.6.585.5f113c2epivA3S