一、服務器數據恢復環境部署介紹：
今天爲大家介紹的數據恢復成功案例服務器型號爲：ORACLE-SUN-ZFS7320。服務器內涉及硬盤32塊，服務器操作採用的是Windows操作系統。
·
二、服務器數據恢復故障情況
服務器在正常運行的時候突然崩潰，沒有斷電、進水、異常操作、機房不穩定等外部因素。服務器管理員對設備進行重啓後發現無法進入系統，需要對服務器內的數據進行恢復。
·
三、分析服務器磁盤底層數據
服務器管理員對所有硬盤進行扇區級鏡像後將鏡像文件送到數據恢復中心進行數據恢復。服務器數據恢復工程師對客戶的故障服務器進行底層數據分析得到如下信息：故障服務器採用zfs文件系統；所有磁盤被分爲4個組，每組8塊硬盤；熱備盤全部啓用。
·
四、服務器故障情況分析
在服務器ZFS文件系統中，池被稱爲ZPOOL。ZPOOL的子設備可以有很多種類，包括塊設備、文件、磁盤等等，在本案例中所採用的是其中的一種------三組RAIDZ作爲子設備。
經過分析發現，三組RAIDZ內有兩組分別啓用熱備盤個數爲1和3。在啓用熱備盤後，第一組內仍出現一塊離線盤，第二組內則出現兩塊。以此進行故障現場模擬：三組RAIDZ內第一二組分別出現離線盤，熱備盤及時進行替換；熱備盤無冗餘狀態下第一組出現一塊離線盤，第二組出現兩塊離線盤，ZPOOL進入高負荷狀態（每次讀取數據都需要進行校驗得到正確數據）；第二組內出現第三塊離線盤，RAIDZ崩潰、ZPOOL下線、服務器崩潰。
·
五、重組ZPOOL，追蹤數據入口
ZFS管理的存儲池與常規存儲不同，所有磁盤都由ZFS進行管理。常規RAID在存儲數據時，只按照特定的規則組建池，不關心文件在子設備上的位置。而ZFS在數據存儲時會爲每次寫入的數據分配適當大小的空間，並計算得到指向子設備的數據指針。這種特性使得RAIDZ缺盤時無法直接進行校驗得到數據，必須將整個ZPOOL作爲一個整體進行解析。
手工截取事務塊數據，編寫程序獲取最大事務號入口：
獲取文件系統入口
獲取到文件系統入口後，編寫數據指針解析程序進行地址解析：
解析數據指針
獲取到文件系統入口點在各磁盤分佈情況後，開始手工截取並分析文件系統內部結構，入口分佈所在的磁盤組無缺失盤，可直接提取信息。根據ZFS文件系統的數據存儲結構順利找到客戶映射的LUN名稱，進而找到其節點。
·
六、編寫數據提取程序並運行
經過仔細分析，發現在此存儲中的ZFS版本與開源版本有較大差別，無法使用公司原先開發的解析程序進行解析，所以重新編寫了數據提取程序。
提取數據程序
由於磁盤組內缺盤個數較多，每個IO流都需要通過校驗得到，提取進度極爲緩慢。與客戶溝通後得知，此ZVOL卷映射到XenServer作爲存儲設備，客戶所需的文件在其中一個大小約爲2T的vhd內。提取ZVOL卷頭部信息，按照XenStore卷存儲結構進行分析，發現2T vhd在整個卷的尾部，計算得到其起始位置後從此位置開始提取數據。
·
七、驗證數據完整性，服務器數據恢復成功
Vhd提取完畢後，對其內部的壓縮包及圖片、視頻等文件進行驗證，均可正常打開。
聯繫客戶驗證數據，確定文件數量與系統自動記錄的文件個數一致。驗證文件可用性，文件全部可正常打開，服務器數據恢復成功。