服務器數據恢復環境&故障：
一臺配有32塊硬盤的服務器在運行過程中突然崩潰不可用。經過初步檢測，基本上確定服務器硬件不存在物理故障。管理員重啟服務器后問題依舊。需要恢復該服務器中的數據。

服務器數據恢復環境：
1、將服務器中硬盤做好標記后取出，硬件工程師檢測后沒有發現有硬盤存在硬件故障，都可以正常讀取。使用專業工具對所有硬盤進行扇區級全盤鏡像。鏡像完成后按照原樣將所有硬盤還原到原服務器中，后續的數據分析和數據恢復操作都基于鏡像文件進行，避免對原始磁盤數據造成二次破壞。
2、基于鏡像文件分析所有磁盤底層數據。通過分析獲取到和故障服務器有關的信息：服務器通過zfs文件系統管理所有磁盤。服務器中的32塊硬盤共創建了4組raidz陣列。兩組raidz陣列硬盤離線后都啟用了熱備盤，熱備盤上線后這兩組raidz陣列中又有硬盤離線。
3、ZFS管理的存儲池與常規存儲池有所不同。常規RAID陣列存儲數據，按照特定的規則組建池，不關心文件在子設備上的位置。ZFS存儲數據會為每次寫入的數據分配適當大小的空間，并計算出指向子設備的數據指針。ZFS的這種特性導致RAIDZ陣列在缺盤時無法直接通過校驗得到數據，而是需要將整個ZPOOL作為整體進行解析。
4、手工截取事務塊數據，數據恢復工程師編寫程序獲取最大事務號入口。
獲取文件系統入口：

北亞企安數據恢復—zfs文件系統數據恢復

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

北亞企安數據恢復—zfs文件系統數據恢復

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

北亞企安數據恢復—zfs文件系統數據恢復

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

審核編輯 黃宇