一、服務(wù)器數據恢復故障描述

　　機房突然斷電導致整個(gè)存儲癱瘓，加電后存儲依然無(wú)法使用。經(jīng)過(guò)用戶(hù)方工程師診斷后認為是斷電導致存儲陣列損壞。

　　整個(gè)存儲是由12塊日立硬盤(pán)(3T SAS硬盤(pán))組成的RAID-6磁盤(pán)陣列，被分成一個(gè)卷，分配給幾臺Vmware的ESXI主機做共享存儲。整個(gè)卷中存放了大量的Windows虛擬機，虛擬機基本都是模板創(chuàng )建的，因此系統盤(pán)都統一為160G。數據盤(pán)大小不確定，并且數據盤(pán)都是精簡(jiǎn)模式。

　　二、服務(wù)器數據恢復備份數據

　　將故障存儲的所有磁盤(pán)和備份sss數據的目標磁盤(pán)連入到一臺Windows Server 2008的服務(wù)器上。

　　使用WinHex 對HD13-HD24以底層方式讀取扇區，發(fā)現了大量損壞扇區。初步判斷可能是這種硬盤(pán)的讀取機制與常見(jiàn)的硬盤(pán)不一樣。嘗試更換操作主機，更換HBA卡，更換擴展柜，更換為L(cháng)inux操作系統，均呈現相同故障。與用戶(hù)方工程師聯(lián)系，對方回應此控制器對磁盤(pán)沒(méi)有特殊要求。

　　使用專(zhuān)業(yè)工具對硬盤(pán)損壞扇區的分布規律進(jìn)行檢測，發(fā)現如下規則：

　　1、損壞扇區分布以256個(gè)扇區為單位。2、除損壞扇區片斷的起始位置不固定外，后面的損壞扇區都是以2816個(gè)扇區為間隔。

　　臨時(shí)寫(xiě)了個(gè)小程序，對每個(gè)磁盤(pán)的損壞扇區做繞過(guò)處理。用此程序鏡像完所有盤(pán)的數據。

　　三、服務(wù)器數據恢復故障分析

　　1、分析損壞扇區

　　仔細分析損壞扇區發(fā)現，損壞扇區呈規律性出現。

　　-每段損壞扇區區域大小總為256。-損壞扇區分布為固定區域，每跳過(guò)11個(gè)256扇區遇到一個(gè)壞的256扇區。-損壞扇區的位置一直存在于RAID的P校驗或Q校驗區域。-所有硬盤(pán)中只有10號盤(pán)中有一個(gè)自然壞道。

　　2、分析分區大小

　　對HD13、HD23、HD24的0-2扇區做分析，可知分區大小為52735352798扇區，此大小按RAID-6的模式計算，除以9，等于5859483644扇區，與物理硬盤(pán)大小1049524，和DS800控制器中保留的RAID信息區域大小吻合;同時(shí)根據物理硬盤(pán)底層表現，分區表大小為512字節，后面無(wú)8字節校驗，大量的0扇區也無(wú)8字節校驗。故可知，原存儲并未啟用存儲中常用的DA技術(shù)(520字節扇區)。

　　四、重組RAID

　　1、分析RAID結構

　　存儲使用的是標準的RAID-6陣列，接下來(lái)只需要分析出RAID 成員數量以及RAID的走向就可以重組RAID。

　　-分析RAID條帶大小

　　整個(gè)存儲被分成一個(gè)大的卷，分配給幾臺ESXI做共享存儲，因此卷的文件系統肯定是VMFS文件系統。而VMFS卷中又有存放了大量的Windows 虛擬機。Windows虛擬機中大多使用的是NTFS文件系統，因此可以根據NTFS中的MFT的順序分析出RAID條帶的大小以及RAID的走向。

　　-分析RAID是否存在掉線(xiàn)盤(pán)

　　鏡像完所有磁盤(pán)。后發(fā)現最后一塊硬盤(pán)中并沒(méi)有像其他硬盤(pán)一樣有大量的壞道。其中有大量未損壞扇區，這些未損壞扇區大多是全0扇區。因此可以判斷這塊硬盤(pán)是熱備盤(pán)。

　　2、重組RAID

　　根據分析出來(lái)的RAID結構重組RAID，能看到目錄結構。但是不確定是否為最新?tīng)顟B(tài)，檢測幾個(gè)虛擬機發(fā)現有部分虛擬機正常，但也有很多虛擬機數據異常。初步判斷RAID中存在掉線(xiàn)的磁盤(pán)，依次將RAID中的每一塊磁盤(pán)踢掉，然后查看剛才數據異常的地方，未果。又仔細分析底層數據發(fā)現問(wèn)題不是出在RAID層面，而是出在VMFS文件系統上。VMFS文件系統如果大于16TB的話(huà)會(huì )存在一些其他的記錄信息，因此在組建RAID的時(shí)候需要跳過(guò)這些記錄信息。再次重組RAID，查看以前數據異常的地方可以對上了。針對其中的一臺虛擬機做驗證，將所有磁盤(pán)加入RIAD中后，這臺虛擬機是可以啟動(dòng)的，但缺盤(pán)的情況下啟動(dòng)有問(wèn)題。因此判斷整個(gè)RAID處在不缺盤(pán)的狀態(tài)為最佳。

　　五、驗證數據

　　1、驗證虛擬機;針對用戶(hù)較為重要的虛擬機做驗證，發(fā)現虛擬機大多都可以開(kāi)機，可以進(jìn)入登陸界面。有部分虛擬機開(kāi)機藍屏或開(kāi)機檢測磁盤(pán)，但是光盤(pán)修復之后都可以啟動(dòng)。

　　2、驗證數據庫;針對重要的虛擬機中的數據庫做驗證，發(fā)現數據庫都正常。其中有一個(gè)數據庫，據用戶(hù)描述是缺少部分數據，但是經(jīng)過(guò)仔細核對后發(fā)現這些數據在數據庫中本來(lái)就不存在。

　　3、檢測整個(gè)VMFS卷是否完整;由于虛擬機的數量很多，每臺都驗證的話(huà)，所需的時(shí)間會(huì )很長(cháng)，因此我們對整個(gè)VMFS卷做檢測。在檢測VMFS卷的過(guò)程中發(fā)現有部分虛擬機或虛擬機的文件被破壞。

　　六、恢復數據

　　1、生成數據;北亞工程師跟客戶(hù)溝通并且描述了目前恢復的情況。用戶(hù)經(jīng)過(guò)對幾臺重要的虛擬機驗證后，用戶(hù)反應恢復的數據可以接受，接著(zhù)北亞工程師立即著(zhù)手準備恢復所有數據。

　　先準備目標磁盤(pán)，使用一臺dell 的MD 1200加上11塊3T的硬盤(pán)組成一個(gè)RAID陣列。接著(zhù)將重組的RAID數據鏡像到目標陣列上。然后利用專(zhuān)業(yè)的工具UFS解析整個(gè)VMFS文件系統。

　　2、嘗試掛載恢復的VMFS卷;將恢復好的VMFS卷連接到我們的虛擬化環(huán)境中的一臺ESXI5.5主機上，嘗試將其掛載到的ESXI5.5的環(huán)境中。但是由于版本(客戶(hù)的ESXI主機是5.0版本)原因或VMFS本身有損壞，導致其掛載不成功。繼續嘗試使用ESXI的命令掛載也不成功，于是放棄掛載VMFS卷。

　　七、移交數據

　　由于時(shí)間緊迫，先安排北亞工程師將MD 1200 陣列上的數據帶到用戶(hù)現場(chǎng)。然后使用專(zhuān)業(yè)工具”UFS”依次導出VMFS卷中的虛擬機。

　　1、將MD 1200陣列上的數據通過(guò)HBA卡連接到用戶(hù)的VCenter服務(wù)器上。

　　2、在VCenter服務(wù)器安裝“UFS”工具，然后使用“UFS”工具解釋VMFS卷。

　　3、使用“UFS”工具將VMFS卷中的虛擬機導入到VCenter服務(wù)器上。

　　4、使用VCenter的上傳功能將虛擬機上傳到ESXI的存儲中。

　　5、接著(zhù)將上傳完的虛擬機添加到清單，開(kāi)機驗證即可。

　　6、如果有虛擬機開(kāi)機有問(wèn)題，則嘗試使用命令行模式修復?；蛘咧亟ㄌ摂M機并將恢復的虛擬機磁盤(pán)(既VMDK文件)拷貝過(guò)去。

　　7、由于部分虛擬機的數據盤(pán)很大，而數據很少。像這種情況就可以直接導出數據，然后新建一個(gè)虛擬磁盤(pán)，最后將導出的數據拷貝至新建的虛擬磁盤(pán)中即可。

　　統計了一下整個(gè)存儲中虛擬機的數量，大約有200臺虛擬機。目前的情況只能通過(guò)上述方式將恢復的虛擬機一臺一臺的恢復到用戶(hù)的ESXI中。由于是通過(guò)網(wǎng)絡(luò )傳輸，因此整個(gè)遷移的過(guò)程中網(wǎng)絡(luò )是一個(gè)瓶頸。經(jīng)過(guò)不斷的調試以及更換主機最終還是無(wú)法達到一個(gè)理想的狀態(tài)，由于時(shí)間緊張，最終還是決定在當前的環(huán)境遷移數據。

　　八、數據恢復總結

　　經(jīng)過(guò)仔細分析后得出壞道的結論如下：

　　-除去SN：YHJ6LEUD上的一個(gè)自然壞道外，其余壞道均分布于RAID-6的Q校驗塊中。

　　-壞道區域多數表現為完整的256個(gè)扇區，正好當時(shí)創(chuàng )建RAID-6時(shí)的一個(gè)完整RAID塊大小。

　　-活動(dòng)區域表現為壞道，非活動(dòng)區域壞道有可能不出現，如熱備盤(pán)，上線(xiàn)不足10%，壞道數量就比其他在線(xiàn)盤(pán)少(熱備盤(pán)的鏡像4小時(shí)完成，其他有壞道盤(pán)大概花費40小時(shí))

　　-其他非Q校驗區域完好，無(wú)任何故障。

　　結論：

　　通常情況，經(jīng)如上壞道規則表現可推斷，壞道為控制器生成Q校驗，向硬盤(pán)下達IO指令時(shí)，可能表現為非標指令，硬盤(pán)內部處理異常，導致出現規律性壞道。

　　數據恢復總結;數據恢復過(guò)程中由于壞道數量太多，以致備份數據時(shí)花費了很長(cháng)世間。整個(gè)存儲是由壞道引起的，導致最終恢復的數據有部分破壞，但不影響整體數據，最終的結果也在可接受范圍內。

　　整個(gè)恢復過(guò)程，用戶(hù)方要求緊急，我方也安排工程師加班加點(diǎn)，最終在最短的時(shí)間內將數據恢復出來(lái)。