伺服器癱瘓導致虛擬機器丟失恢復過程

一、伺服器資料恢復故障描述

機房突然斷電導致整個儲存癱瘓，加電後儲存依然無法使用。經過使用者方工程師診斷後認為是斷電導致儲存陣列損壞。
整個儲存是由12塊日立硬碟（3T SAS硬碟）組成的RAID-6磁碟陣列，被分成一個卷，分配給幾臺Vmware的ESXI主機做共享儲存。整個卷中存放了大量的Windows虛擬機器，虛擬機器基本都是模板建立的，因此係統盤都統一為160G。資料盤大小不確定，並且資料盤都是精簡模式。

二、備份伺服器資料

將故障儲存的所有磁碟和備份sss資料的目標磁碟連入到一臺Windows Server 2008的伺服器上。故障磁碟都設為離線（只讀）狀態，在專業工具WinHex下看到連線狀態如下圖所示：(圖中HD1-HD12為目標備份磁碟，HD13-HD24為源故障磁碟，型號為HUS723030ALS640)：
圖一：

使用WinHex 對HD13-HD24以底層方式讀取扇區，發現了大量損壞扇區。初步判斷可能是這種硬碟的讀取機制與常見的硬碟不一樣。嘗試更換操作主機，更換HBA卡，更換擴充套件櫃，更換為Linux作業系統，均呈現相同故障。與使用者方工程師聯絡，對方回應此控制器對磁碟沒有特殊要求。
使用專業工具對硬碟損壞扇區的分佈規律進行檢測，發現如下規則：
1、損壞扇區分佈以256個扇區為單位。
2、除損壞扇區片斷的起始位置不固定外，後面的損壞扇區都是以2816個扇區為間隔。
所有磁碟的損壞扇區分佈如下表（只列出前3個損壞扇區）：


臨時寫了個小程式，對每個磁碟的損壞扇區做繞過處理。用此程式映象完所有盤的資料。

三、伺服器資料分析

1、分析損壞扇區
仔細分析損壞扇區發現，損壞扇區呈規律性出現。
-每段損壞扇區區域大小總為256。
-損壞扇區分佈為固定區域，每跳過11個256扇區遇到一個壞的256扇區。
-損壞扇區的位置一直存在於RAID的P校驗或Q校驗區域。
-所有硬碟中只有10號盤中有一個自然壞道。

2、分析分割槽大小
對HD13、HD23、HD24的0-2扇區做分析，可知分割槽大小為52735352798扇區，此大小按RAID-6的模式計算，除以9，等於5859483644扇區，與物理硬碟大小1049524，和DS800控制器中保留的RAID資訊區域大小吻合；同時根據物理硬碟底層表現，分割槽表大小為512位元組，後面無8位元組校驗，大量的0扇區也無8位元組校驗。故可知，原儲存並未啟用儲存中常用的DA技術(520位元組扇區）。
分割槽大小如下圖(GPT分割槽表項底層表現，塗色部分表示分割槽大小，單位512位元組扇區，64bit)：
圖二：

四、重組RAID

1、分析RAID結構
儲存使用的是標準的RAID-6陣列，接下來只需要分析出RAID 成員數量以及RAID的走向就可以重組RAID。
-分析RAID條帶大小
整個儲存被分成一個大的卷，分配給幾臺ESXI做共享儲存，因此卷的檔案系統肯定是VMFS檔案系統。而VMFS卷中又有存放了大量的Windows 虛擬機器。Windows虛擬機器中大多使用的是NTFS檔案系統，因此可以根據NTFS中的MFT的順序分析出RAID條帶的大小以及RAID的走向。
-分析RAID是否存在掉線盤
映象完所有磁碟。後發現最後一塊硬碟中並沒有像其他硬碟一樣有大量的壞道。其中有大量未損壞扇區，這些未損壞扇區大多是全0扇區。因此可以判斷這塊硬碟是熱備盤。

2、重組RAID
根據分析出來的RAID結構重組RAID，能看到目錄結構。但是不確定是否為最新狀態，檢測幾個虛擬機器發現有部分虛擬機器正常，但也有很多虛擬機器資料異常。初步判斷RAID中存在掉線的磁碟，依次將RAID中的每一塊磁碟踢掉，然後檢視剛才資料異常的地方，未果。又仔細分析底層資料發現問題不是出在RAID層面，而是出在VMFS檔案系統上。VMFS檔案系統如果大於16TB的話會存在一些其他的記錄資訊，因此在組建RAID的時候需要跳過這些記錄資訊。再次重組RAID，檢視以前資料異常的地方可以對上了。針對其中的一臺虛擬機器做驗證，將所有磁碟加入RIAD中後，這臺虛擬機器是可以啟動的，但缺盤的情況下啟動有問題。因此判斷整個RAID處在不缺盤的狀態為最佳。

五、驗證伺服器資料

1、驗證虛擬機器
針對使用者較為重要的虛擬機器做驗證，發現虛擬機器大多都可以開機，可以進入登陸介面。有部分虛擬機器開機藍色畫面或開機檢測磁碟，但是光碟修復之後都可以啟動。
部分虛擬機器現象開機如下：
圖三：

2、驗證資料庫
針對重要的虛擬機器中的資料庫做驗證，發現資料庫都正常。其中有一個資料庫，據使用者描述是缺少部分資料，但是經過仔細核對後發現這些資料在資料庫中本來就不存在。透過查詢 master 資料庫中的系統檢視，查出原來的所有資料庫資訊如下：
圖四：

3、檢測整個VMFS卷是否完整
由於虛擬機器的數量很多，每臺都驗證的話，所需的時間會很長，因此我們對整個VMFS卷做檢測。在檢測VMFS卷的過程中發現有部分虛擬機器或虛擬機器的檔案被破壞。列表如下：
圖五：

六、伺服器資料恢復成功

1、生成資料
北亞工程師跟客戶溝通並且描述了目前恢復的情況。使用者經過對幾臺重要的虛擬機器驗證後，使用者反應恢復的資料可以接受，接著北亞工程師立即著手準備恢復所有資料。
先準備目標磁碟，使用一臺dell 的MD 1200加上11塊3T的硬碟組成一個RAID陣列。接著將重組的RAID資料映象到目標陣列上。然後利用專業的工具UFS解析整個VMFS檔案系統。
2、嘗試掛載恢復的VMFS卷
將恢復好的VMFS卷連線到我們的虛擬化環境中的一臺ESXI5.5主機上，嘗試將其掛載到的ESXI5.5的環境中。但是由於版本（客戶的ESXI主機是5.0版本）原因或VMFS本身有損壞，導致其掛載不成功。繼續嘗試使用ESXI的命令掛載也不成功，於是放棄掛載VMFS卷。

七、移交資料

由於時間緊迫，先安排北亞工程師將MD 1200 陣列上的資料帶到使用者現場。然後使用專業工具”UFS”依次匯出VMFS卷中的虛擬機器。
1、將MD 1200陣列上的資料透過HBA卡連線到使用者的VCenter伺服器上。
2、在VCenter伺服器安裝“UFS”工具，然後使用“UFS”工具解釋VMFS卷。
3、使用“UFS”工具將VMFS卷中的虛擬機器匯入到VCenter伺服器上。
4、使用VCenter的上傳功能將虛擬機器上傳到ESXI的儲存中。
5、接著將上傳完的虛擬機器新增到清單，開機驗證即可。
6、如果有虛擬機器開機有問題，則嘗試使用命令列模式修復。或者重建虛擬機器並將恢復的虛擬機器磁碟（既VMDK檔案）複製過去。
7、由於部分虛擬機器的資料盤很大，而資料很少。像這種情況就可以直接匯出資料，然後新建一個虛擬磁碟，最後將匯出的資料複製至新建的虛擬磁碟中即可。
統計了一下整個儲存中虛擬機器的數量，大約有200臺虛擬機器。目前的情況只能透過上述方式將恢復的虛擬機器一臺一臺的恢復到使用者的ESXI中。由於是透過網路傳輸，因此整個遷移的過程中網路是一個瓶頸。經過不斷的除錯以及更換主機最終還是無法達到一個理想的狀態，由於時間緊張，最終還是決定在當前的環境遷移資料。

八、伺服器資料恢復總結

1、故障總結
所有磁碟壞道的規律如下表：


經過仔細分析後得出壞道的結論如下：
-除去SN：YHJ6LEUD上的一個自然壞道外，其餘壞道均分佈於RAID-6的Q校驗塊中。
-壞道區域多數表現為完整的256個扇區，正好當時建立RAID-6時的一個完整RAID塊大小。
-活動區域表現為壞道，非活動區域壞道有可能不出現，如熱備盤，上線不足10%，壞道數量就比其他線上盤少（熱備盤的映象4小時完成，其他有壞道盤大概花費40小時）
-其他非Q校驗區域完好，無任何故障。
結論：
通常情況，經如上壞道規則表現可推斷，壞道為控制器生成Q校驗，向硬碟下達IO指令時，可能表現為非標指令，硬碟內部處理異常，導致出現規律性壞道。
2、資料恢復總結
資料恢復過程中由於壞道數量太多，以致備份資料時花費了很長世間。整個儲存是由壞道引起的，導致最終恢復的資料有部分破壞，但不影響整體資料，最終的結果也在可接受範圍內。
整個恢復過程，使用者方要求緊急，我方也安排工程師加班加點，最終在最短的時間內將資料恢復出來。後續的資料遷移過程中由我方工程師和使用者方工程師配合完成。