服務器數據恢復環境：
ORACLE SUN ZFS某型號存儲，共40塊磁盤組建存儲池，其中的36塊磁盤分為三組，每組12塊，單個組使用ZFS特有的RAIDZ管理所有磁盤，RAIDZ級別為2；另外的4塊磁盤作為全局熱備。存儲池內劃分出若干空間映射到服務器使用。

北亞企安數據恢復——ZFS數據恢復

服務器故障：
服務器正常運行過程中崩潰，服務器管理員重啟設備后無法進入系統。通過對服務器和存儲的初步檢測以及和管理人員的溝通，排除了斷電、進水、異常操作等外部因素。

北亞企安數據恢復——ZFS數據恢復

服務器數據恢復過程：
1、將存儲中所有磁盤編號后取出，硬件工程師檢測后沒有發現有硬盤存在硬件故障。以只讀方式將所有磁盤進行扇區級全盤鏡像，鏡像完成后按照編號將所有磁盤還原到原存儲中。后續的數據分析和數據恢復操作都基于鏡像文件進行，避免對原始磁盤數據造成二次破壞。
2、基于磁盤鏡像文件分析底層數據，發現全局熱備盤全部啟用。
在ZFS文件系統中，ZPOOL（池）的子設備有很多種類：塊設備、文件、磁盤等，本案例中三組RAIDZ作為子設備。
分析底層數據發現，三組RAIDZ中的兩組RAIDZ分別啟用的熱備盤個數為1和3。北亞企安數據恢復工程師基于獲取到的信息推斷故障過程：熱備盤啟用后，在熱備盤無冗余狀態下，第一組RAIDZ中又有一塊磁盤離線，第二組RAIDZ中則又有兩塊磁盤離線，ZPOOL進入高負荷狀態；直到第二組RAIDZ中第三塊盤離線，RAIDZ崩潰，ZPOOL下線，服務器崩潰。
ZFS管理的存儲池中所有磁盤都由ZFS進行管理。常規RAID按照特定的規則組建池，并不關心文件在子設備上的位置；而ZFS會為每次寫入的數據分配適當大小的空間，并計算得到指向子設備的數據指針。RAIDZ這種特性導致RAIDZ缺盤時無法直接通過校驗得到數據，而必須將整個ZPOOL作為一個整體進行解析。
3、手工截取事務塊數據，北亞企安數據恢復工程師編寫程序獲取最大事務號入口。
獲取文件系統入口：

北亞企安數據恢復——ZFS數據恢復

獲取到文件系統入口后，北亞企安數據恢復工程師編寫數據指針解析程序解析地址。
解析數據指針：

北亞企安數據恢復——ZFS數據恢復

4、獲取到文件系統入口點在各磁盤分布情況后，北亞企安數據恢復工程師手動截取&分析文件系統內部結構。由于入口分布所在的磁盤組無缺失盤，可直接提取信息。根據ZFS的數據存儲結構順利找到映射的LUN名稱，然后找到其節點。
5、北亞企安數據恢復工程師編寫解析程序解析ZFS&提取數據。
編輯配置文件，提取ZVOL卷：

北亞企安數據恢復——ZFS數據恢復

6、由于磁盤組內缺盤數目較多，每個IO流都需要通過校驗得到，提取進度極為緩慢。通過和用戶溝通后得知用戶需要恢復的數據在一個vhd內，經過分析發現這個vhd在ZVOL卷的尾部，計算其起始位置后從此位置開始提取數據。
7、Vhd提取完畢后，驗證其內部的壓縮包、圖片、視頻等文件，均可正常打開。
8、用戶方對數據進行驗證，經過驗證發現恢復出來的文件數量與系統自動記錄的文件數量基本一致，文件全部可以正常打開。本次服務器數據恢復工作完成。

審核編輯 黃宇