Apsara HBase 備份恢復
所有的資料庫產品都有備份恢復，Apache HBase官方目前沒有一個release版本的備份恢復功能，官網提出的方案和機制操作都是很複雜。所以阿里雲賦能HBase的備份恢復能力並支援全量和增量的備份和恢復，同時具有高效能、低成本和低線上影響充分自動化。而且備份恢復是獨立於HBase之外的模組，不影響HBase的正常使用，並且備份恢復模組有自有failover的能力，保證備份恢復的持續性。

Apsara-HBase 備份恢復組成圖

1.獨立於Apsara-HBase的備份恢復模組，提供獨立的模組支撐
2.支援全量/增量恢復以及全量/增量恢復，高資料恢復精確度
3.全量/增量備份有failover模組保證資料安全備份
4.支援冷熱分離等統一檔案系統介面，並支同時持HBase的1.x、2.x版本的介面
5.資料備份到oss，擁有極高的資料可靠性，且儲存成本低廉，oss上備份資料不會存在冗餘的情況

**雲HBase備份恢復原理
整體組成**

1.備份包括全量備份和增量備份，全量備份是在某個時刻的全量備份，增量備份是從某個時刻起的Hlog的備份，同時也會對兩種備份資料壓縮。
2.恢復也包括全量恢復和增量恢復，增量恢復是指從最近的全量恢復的時間點到指定的時間點的Hlog的增量恢復，全量恢復是指定時間點最近的一次全量備份資料恢復。
如圖所示，恢復全量備份點2和增量備份點4的資料： 全量恢復使用bulkload 增量恢復使用的是replay

相關指標

1.全量備份最長時間限制是4天
2.全量恢復最長時間是1.5天
3.RPO(Recover Pointobjective)業務系統所能容忍的資料丟失量是1小時，二期會支援秒級
4.資料可靠性高達11個9（99.9999999%）且OSS儲存成本極低
5.定期清理過期備份資料，可以降低備份資料的冗餘
備份部分：全量備份

全量備份的架構圖如下：

RS和MASTER的排程身份有所不同，如上圖master節點會做snapshot的備份，RS節點做的是Hfile的備份，上轉任務切分實現了兩種方案 a) round robin近均勻策略 b) 基於short-circuit read的切分策略。使用failover機制保證失敗重試，且基於Hfilelink，追蹤hfile路徑，保證讀到資料。

備份部分：增量備份

增量備份的架構如下：

正常情況下，各個hlogserver負責自己機器相關的hlog，並且實時收集備份hlog，備份精度在一小時以內。實現Hloglink，追蹤hlog全鏈路的蹤跡，保證讀到資料；追蹤WALs/oldWALs/splitting 3種狀態，記憶體佔用量只有20MB。 hlogserver採用了round robin takeover 策略保證不會漏備任何一條hlog。

下圖是Hlogserver failover是的示意圖：

當Hlogserver1服務和ecsdown機的時候，Hlogserver會把Hlogserver1當前的任務log13、log14轉給Hlogserver2執行。如果Hlogserver1恢復服務的時候log1x相關的任務會繼續在Hlogserver1上執行。

恢復部分

架構圖如下：

服務會根據需要的時間點恢復最近的一次全量備份和全量備份的時間點到需要恢復的時間點的增量Hlog備份。並且Hfile和Hlog的恢復都是各節點分散式執行的。

阿里雲HBase 備份恢復 vs 其他大資料資料庫備份恢復

下面的表格是阿里Hbase和其它Hbase備份恢復的對比

DB備份恢復

備份

恢復

阿里雲HBase

全量備份，增量實時備份，保證備份精度，備份目標端保證低資料冗餘

全量bulkload+log replay，可以恢復任意合理的叢集規模

Apache HBase

社群方案需要依賴mr，且一次全量，以後都增量，增量備份精度有限，且存在資料冗餘

全部hfile bulkload模式，速度較快。

Apache Cassandra

全量組合增量模式，可能引入多份冗餘增量log的出口頻寬

需要恢復到備份對等的叢集規模

文章來自：郭鵬——HBase生態+Spark社群大群 志願者