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

　　機房突然斷電導致整個存儲癱瘓，加電后存儲依然無法使用。經過用戶方工程師診斷后認為是斷電導致存儲陣列損壞。

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

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

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

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

　　使用專業(yè)工具對硬盤損壞扇區(qū)的分布規(guī)律進行檢測，發(fā)現(xiàn)如下規(guī)則：

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

　　臨時寫了個小程序，對每個磁盤的損壞扇區(qū)做繞過處理。用此程序鏡像完所有盤的數(shù)據(jù)。

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

　　1、分析損壞扇區(qū)

　　仔細分析損壞扇區(qū)發(fā)現(xiàn)，損壞扇區(qū)呈規(guī)律性出現(xiàn)。

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

　　2、分析分區(qū)大小

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

　　四、重組RAID

　　1、分析RAID結構

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

　　-分析RAID條帶大小

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

　　-分析RAID是否存在掉線盤

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

　　2、重組RAID

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

　　五、驗證數(shù)據(jù)

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

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

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

　　六、恢復數(shù)據(jù)

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

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

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

　　七、移交數(shù)據(jù)

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

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

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

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

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

　　5、接著將上傳完的虛擬機添加到清單，開機驗證即可。

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

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

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

　　八、數(shù)據(jù)恢復總結

　　經過仔細分析后得出壞道的結論如下：

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

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

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

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

　　結論：

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

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

　　整個恢復過程，用戶方要求緊急，我方也安排工程師加班加點，最終在最短的時間內將數(shù)據(jù)恢復出來。