服務器存儲數據恢復環境：
ZFS Storage 7320存儲陣列中有32塊硬盤。32塊硬盤分為4組，每組8塊硬盤，共組建了3組RAIDZ，每組raid都配置了熱備盤。

服務器存儲故障：
服務器存儲運行過程中突然崩潰，排除人為誤操作、斷電、進水和其他機房不穩定因素。管理員重啟服務器存儲，系統無法進入，需要恢復服務器存儲中的數據。

服務器存儲數據恢復過程：
1、將故障服務器存儲中所有硬盤標記后取出，以只讀方式進行扇區級完整鏡像，鏡像完成后將所有磁盤按照原樣還原到原存儲中，后續的數據分析和數據恢復操作都基于鏡像文件進行，避免對原始磁盤數據造成二次破壞。
2、基于鏡像文件分析所有硬盤中的底層數據，發現服務器存儲中的熱備盤全部啟用，上層采用ZFS文件系統。
Tips：
在ZFS文件系統中，存儲池被稱為ZPOOL。ZPOOL可以有各種類別的子設備：塊設備、文件、磁盤等等。本案例中ZPOOL的子設備是三組RAIDZ作為子設備。
經過對底層數據的分析發現，三組RAIDZ中的兩組RAIDZ啟用的熱備盤的個數分別為1和3。啟用熱備盤后，第一組RAIDZ中又有一塊盤離線，第二組RAIDZ中則又有兩塊硬盤離線。
根據上述分析結果模擬故障現場：三組RAIDZ中的兩組RAIDZ出現硬盤離線的情況，熱備盤自動上線替換離線盤。在熱備盤無冗余的情況下第一組RAIDZ中又有一塊盤離線，第二組RAIDZ中則有兩塊盤離線，ZPOOL進入高負荷狀態（每次讀取數據都需要校驗）；當第二組RAIDZ中出現第三塊離線盤的時候，該組RAIDZ崩潰，ZPOOL下線，服務器存儲崩潰。
3、ZFS管理的存儲池與常規存儲池不同。在ZFS文件系統下，ZFS管理所有磁盤。常規RAID在存儲數據時會按照特定的規則組建池，并不關心文件在子設備上的位置。在ZFS下，存儲數據時會為每次寫入的數據分配適當大小的空間，并計算出指向子設備的數據指針。所以RAIDZ缺盤時無法直接通過校驗得到數據，必須將整個ZPOOL作為一個整體進行解析。
4、北亞企安數據恢復工程師手工截取事務塊數據，并編寫程序獲取最大事務號入口。
獲取文件系統入口：

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

6、獲取到文件系統入口點在各磁盤上的分布情況后，北亞企安數據恢復工程師開始手工截取并分析文件系統內部結構。入口點所在的磁盤組無缺失盤，可直接提取信息。根據ZFS文件系統的數據存儲結構順利找到映射的LUN的名稱，進而找到其節點。
7、經過分析發現此存儲中的ZFS版本與開源版本有較大差別，無法使用之前開發的解析程序進行解析，所以北亞企安數據恢復工程師重新編寫程序進行解析。

8、由于缺盤個數較多，每個IO流都需要通過校驗得到，進度極為緩慢。與用戶方溝通后得知此ZVOL卷映射到XenServer作為存儲設備，所需要的文件在一個vhd內。提取ZVOL卷頭部信息，按照XenStore卷存儲結構進行分析，發現該vhd在整個卷的尾部。計算出其起始位置后從此位置開始提取數據。
9、Vhd提取完畢后，驗證其內部的壓縮包、圖片、視頻等文件，均可正常打開。
10、交由用戶方驗證恢復出來的數據。經過驗證，發現恢復出來的文件數量與系統自動記錄的文件數量差不多，稍微有點出入。丟失的極少量文件應該是因為這些文件是新生成的還未存儲到磁盤。隨機驗證恢復出來的文件，全部可正常打開。用戶方認可數據恢復結果。