儲存資料恢復初檢方式：根據與客戶**溝通及現場檢測，按故障表現，作如下判斷：
故障表現：客戶共配置16臺伺服器節點，在每台物理伺服器儲存上，有大約3臺左右的虛擬機器，在虛擬機器上配置的分布式，上層部署的hbase資料庫和hive資料庫，資料庫底層檔案刪除，導致資料庫不能使用。
經過現場對客戶環境的簡單檢測，虛擬機器還可以正常啟動，虛擬機器裡面的資料庫塊檔案有丟失，塊檔案丟失之後，沒有對整個集群環境在進行資料的寫入，底層的資料損壞可能性會比較小。
綜上所述，由於在刪除之後，沒有在繼續寫入資料，具有較大的可恢復性，但是由於現階段還沒有對底層結構進行分析，再加上hbase和hive的演算法和底層結構十分複雜，具體的恢復概率無法判斷，還需在之後具體的資料恢復過程中才可以知曉。
1、前期備份流程
a、從物理伺服器儲存底層做備份，將原儲存裝置斷電、關機。
b、從虛擬機器層面備份，通過網路直接備份虛擬機器底層磁碟檔案。
c、準備一台恢復操作伺服器（北亞提供），在資料恢復平台上以唯讀方式掛載伺服器硬碟，使用北亞磁碟備份工具(或 dd等工具)進行完整的扇區對扇區的備份。
d、備份完成後，提供詳細報告，涉及威信的健康狀態及可能存在的壞道列表。
e、將伺服器硬碟交回給使用者(建議原樣恢復)，之後不再直接操作原介質。
2、伺服器儲存塊檔案結構分析
a、對每個虛擬機器磁碟的塊檔案進行分析；
b、分析檔案底層的聚合方式；
c、分析每個磁碟中資料的分布情況；
3、block檔案key分析
a、定位資料庫檔案中的key資訊；
b、提取並解析資料庫檔案中key資訊；
c、整合資料庫檔案key資訊。
4、block檔案拼接
a、根據block檔案的key資訊提取檔案片段；
b、對block檔案的片段進行拼接；
c、校驗拼接後的block檔案的正確性。
5、block檔案匯入
a、校驗提取出的block檔案完整性及正確性；
b、把提取出來的block檔案匯入到hbase和hive資料庫中；
6、伺服器儲存資料恢復結果驗證
a、由使用者主導對資料本身進行詳細驗證。
b、如發現新問題，重新檢驗上述所有資料恢復過程。
1、整個過程不會對客戶的原盤有任何的寫操作，以確保原盤的資料安全
2、盡最大可能保證服務的操作可逆，確保人力可控範圍內操作可回溯。
3、提供後期資料保管和服務跟蹤。
4、以上所有操作在有備份的情況下進行，若不成功不影響其他方案繼續。
說明：總時間控制在20個工作日，上表中的時間只是預估，以實際情況為準。
資料安全救援的可靠度應超過 80%。參考：2023年全年企業級資料安全救援的最終成功率為 84.3%。因不存在同步及基本可排除的硬體故障。
ceph 分布式 儲存服務 恢復
systemctl isolate multi user.target適用於 ceph 15 octopus cephadm 自動部署 知曉 fsid 大部分檔案未丟失 完整步驟可以參考 官網，或者博主的 其他 ceph 系列部落格 cephadm 依賴 python36 安裝時，請開啟 工具 cu...
Linux部署Hbase分布式檔案儲存
1 zookeeper完成部署,並且集群能夠成功啟動 1.1進入目錄 cd training zookeeper 3.4.5 bin 2 啟動 zkserver.sh start 3 檢視狀態 zkserver.sh status 2 hadoop集群部署,並且集群能夠成功啟動 cd trainin...
HBASE完全分布式
1.將hbase通過xftp傳入red hat 2.tar zxvf hbase c usr local 解壓到目錄下 3.cd usr local hbase conf 到conf修改hbase env.sh,hbase site.xml 4.vi hbase env.sh 4.1.set nu ...