服務器數據恢復環境：
1臺某品牌EVA4400控制器+3臺EVA4400擴展柜+28塊FC硬盤。

服務器故障：
由于兩塊磁盤掉線導致存儲中某些LUN不可用，某些LUN丟失，導致存儲崩潰。

服務器數據恢復過程：
1、由于EVA4400存儲故障是某些磁盤掉線導致的，因此收到故障存儲中的所有磁盤后，硬件工程師先對所有磁盤做物理故障檢測，檢測完成后發現所有磁盤均不存在明顯物理故障。使用壞道檢測工具檢測也沒有發現壞道。
磁盤壞道檢測日志截圖：

將所有磁盤以只讀方式進行扇區級全盤鏡像，鏡像完成后將所有磁盤還給用戶方。后續的數據分析和數據恢復操作都基于鏡像文件進行，避免對原始磁盤數據造成二次破壞。
備份完部分數據截圖：

由于沒有檢測到磁盤存在物理故障或者壞道，可以初步判斷磁盤掉線是由于某些磁盤讀寫不穩定導致的。EVA控制器檢查磁盤策略比較嚴格，EVA控制器通常將性能不穩定的磁盤識別為壞盤并踢出磁盤組。一旦某個LUN的同一個條帶中掉線的盤到達極限，這個LUN將不可用。如果EVA存儲中所有LUN都包含這些掉線的盤，所有LUN都會受影響。所以兩塊盤掉線導致整個EVA存儲的LUN都不可用的情況是有可能發生的。故障EVA存儲目前的情況就是8個LUN正常，7個LUN損壞，6個LUN丟失。需要恢復所有LUN的數據。
2、基于鏡像文件分析所有硬盤的底層數據。EVA存儲中的LUN都是以RAID條目的形式存儲數據的，EVA存儲將每個磁盤的不同塊組成一個RAID條目。RAID條目的類型有很多種，首先需要分析出組成LUN的RAID條目類型以及這個RAID條目是由哪些盤的哪些塊組成。這些信息都存放在LUN_MAP中，每個LUN都有一份LUN_MAP。EVA將LUN_MAP分別存放在不同的磁盤中，使用一個索引來指定其位置，因此在每個磁盤中找這個指向LUN_MAP的索引就可以找到現存LUN的信息了。
3、雖然磁盤中記錄了指向LUN_MAP的索引，但是它只記錄現存的LUN，丟失的LUN是不會記錄索引的。EVA存儲中刪除一個LUN只會清除這個LUN的索引，而不會清除這個LUN的LUN_MAP。掃描所有磁盤找到所有符合LUN_MAP的數據塊，然后排除掉現有的LUN_MAP，剩下的LUN_MAP也不一定全是刪除的，也有一些是以前舊的。只能將所有LUN_MAP的數據都恢復出來，人工核對哪些LUN是刪除的。
4、這些由于性能不穩定而掉線的磁盤中存放的是一些舊的數據，在生成數據的時候需要將這些磁盤都排除掉。如何判斷哪些磁盤是掉線的呢？由于本案例中LUN基本上都是RAID5陣列，只需要將一個LUN的RAID條目通過RAID5的校驗算法算出校驗值，再和原有的校驗值做比較就可以判斷這個條目中是否有掉線盤。將一個LUN的所有LUN_MAP都校驗一遍就可以知道這個LUN中的哪些RAID條目中有掉線盤。而這些RAID條目中都存在的那個盤就一定是掉線盤。排除掉線盤，然后根據LUN_MAP恢復所有LUN的數據。
5、北亞企安數據恢復工程師編寫掃描LUN_MAP的程序掃描全部LUN_MAP，結合人工分析獲取到準確的LUN_MAP。編寫檢測RAID條目的程序檢測所有LUN中掉線的磁盤，結合人工分析排除掉線的磁盤。編寫LUN數據恢復程序結合LUN_MAP恢復所有LUN數據。人工核對每個LUN，確認是否和用戶方描述的一致。部分LUN的數據截圖：

6、根據用戶方描述，所有LUN的數據可以分成兩大部份：Vmware虛擬機和HP-UX上的裸設備，裸設備里存放的是Oracle的dbf數據庫。由于恢復的是LUN，無法看到里面的文件，需要人工核對哪些LUN是存放Vmware的數據，哪些是HP-UX的裸設備。然后將LUN掛載到不同的驗證環境中驗證恢復的數據是否完整。
7、Vmware虛擬機和裸設備中oracle數據庫的驗證這里就不贅述了。
8、將所有恢復出來的數據移交到用戶方準備好的環境中，經過驗證，用戶方確認恢復出來的數據完整有效，認可數據恢復結果。本次數據恢復工作完成。

審核編輯 黃宇