服務器存儲數據恢復環境:
一臺存儲中有一組由12塊SAS硬盤組建的RAID6磁盤陣列,劃分為一個卷,分配給幾臺Vmware ESXI主機做共享存儲。該卷中存放了大量Windows虛擬機,這些虛擬機系統盤是統一大小,數據盤大小不確定,數據盤是精簡模式。
服務器存儲故障:
機房斷電導致服務器存儲異常關機,加電后存儲無法使用。
服務器存儲數據恢復過程:
1、將故障服務器存儲的所有磁盤和備份數據的目標磁盤接入到Windows Server服務器上。將磁盤都設為脫機(只讀)狀態,看到的連接狀態如下所示(HD1-HD12為目標備份磁盤,HD13-HD24為源故障磁盤,型號為HUS723030ALS640):
北亞企安數據恢復——存儲數據恢復
2、使用工具在底層讀取HD13-HD24扇區,發現了大量損壞扇區,數據恢復工程師初步推斷出現這種情況的原因是這種硬盤的讀取機制與常見硬盤不一樣。嘗試更換主機、HBA卡、擴展柜,并將操作系統更換為Linux,均呈現相同故障表現。與用戶方工程師溝通,用戶方工程師回應此控制器對磁盤沒有特殊要求。
檢測硬盤損壞扇區的分布規律,服務器數據恢復工程師發現以下規則:
a、損壞扇區分布以256個扇區為單位。
b、除損壞扇區片斷的起始位置不固定外,后面的損壞扇區都是以2816個扇區為間隔。
所有磁盤的損壞扇區(部分)分布:
北亞企安數據恢復——存儲數據恢復
北亞企安數據恢復工程師編寫小程序,繞過處理每個磁盤的損壞扇區,將所有盤的數據做只讀鏡像。
3、基于鏡像文件分析所有磁盤的底層數據。
經過分析發現損壞扇區呈規律性出現:
-每段損壞扇區區域大小總為256。
-損壞扇區分布為固定區域,每跳過11個256扇區遇到一個壞的256扇區。
-損壞扇區的位置一直存在于RAID的P校驗或Q校驗區域。
-所有硬盤中只有10號盤中有一個自然壞道。
分析HD13、HD23、HD24的0-2扇區得知分區大小為52735352798扇區,按RAID6的模式計算,將分區大小除以9等于5859483644扇區,與物理硬盤大小以及DS800控制器中保留的RAID信息區域大小吻合。根據物理硬盤底層表現,分區表大小為512字節,后面無8字節校驗,大量的0扇區也無8字節校驗。故原存儲并未啟用存儲中常用的DA技術(520字節扇區)。
分區大小如下圖(GPT分區表項底層表現,涂色部分表示分區大小,單位512字節扇區,64bit):
北亞企安數據恢復——存儲數據恢復
4、存儲使用的是標準RAID6陣列,只需要分析出RAID成員盤數量以及RAID走向就可以重組RAID。
-分析RAID條帶大小
整個存儲被劃分為一個大的卷,分配給幾臺ESXI做共享存儲,卷的文件系統是VMFS。該VMFS卷中存放了大量的Windows虛擬機。Windows虛擬機大多使用NTFS文件系統,因此可以根據NTFS中MFT的順序分析出RAID條帶大小以及RAID走向。
-分析RAID是否存在掉線盤
鏡像完所有磁盤后發現最后一塊硬盤中并沒有像其他硬盤一樣有大量的壞道。最后一塊硬盤中有大量未損壞扇區,這些未損壞扇區大多是全0扇區,因此可以判斷這塊硬盤是熱備盤。
5、根據分析出來的RAID結構重組RAID。重組完成后能看到目錄結構,但不確定是否為最新狀態。隨機檢測幾個虛擬機發現部分虛擬機數據異常,初步判斷RAID中存在掉線的磁盤。依次將RAID中的每一塊磁盤踢掉,然后查看剛才數據異常的地方,沒有找到問題原因。
6、分析底層數據后發現問題不是出在RAID層面,而是出在VMFS文件系統層面。由于VMFS文件系統如果大于16TB會存在一些其他的記錄信息,因此在組建RAID的時候需要跳過這些記錄信息。再次重組RAID后查看以前數據異常的地方,已經沒有問題了。
針對其中的一臺虛擬機做驗證,將所有磁盤加入RIAD中后,這臺虛擬機是可以啟動的,但缺盤的情況下啟動有問題,因此可以判斷整個RAID處在不缺盤的狀態為最佳。
驗證數據:
1、驗證虛擬機
驗證較為重要的虛擬機,發現大多數虛擬機都可以開機,進入登錄界面。部分虛擬機開機藍屏或開機檢測磁盤,但是使用光盤修復之后都可以正常啟動。
部分虛擬機開機如下:
北亞企安數據恢復——存儲數據恢復
2、驗證數據庫
驗證重要虛擬機中的數據庫,發現數據庫都正常。通過查詢master數據庫中的系統視圖,查出所有數據庫信息如下:
北亞企安數據恢復——存儲數據恢復
3、檢測整個VMFS卷是否完整
由于虛擬機數量很多,每臺都驗證的話,所需的時間會很長,因此檢測整個VMFS卷,在檢測VMFS卷的過程中發現部分虛擬機或虛擬機的文件被破壞。
北亞企安數據恢復——存儲數據恢復
批量恢復數據:
1、和用戶方溝通并且通報了目前恢復數據的情況。用戶對幾臺重要的虛擬機進行驗證后,認可恢復的數據。于是北亞企安數據恢復工程師著手恢復所有數據。
準備好目標RAID,將重組的RAID數據鏡像到目標陣列上,然后使用工具解析整個VMFS。
2、將恢復出來的VMFS卷連接到虛擬化環境中的一臺ESXI5.5主機上,嘗試將該VMFS卷掛載到的ESXI5.5的環境中。由于版本(用戶方的ESXI主機是5.0版本)原因或VMFS本身有損壞,導致掛載不成功。
移交數據:
北亞企安數據恢復工程師將目標陣列上的數據帶到用戶方現場,使用工具導出VMFS卷中的虛擬機。
1、將目標陣列上的數據通過HBA卡連接到用戶的VCenter服務器上。
2、在VCenter服務器安裝工具,然后使用工具解釋VMFS卷。
3、使用工具將VMFS卷中的虛擬機導入到VCenter服務器上。
4、使用VCenter的上傳功能將虛擬機上傳到ESXI的存儲中。
5、將上傳完的虛擬機添加到清單,開機驗證。
6、如果有虛擬機開機出現問題,則嘗試使用命令行模式修復;或者重建虛擬機并將恢復的虛擬機磁盤(既VMDK文件)拷貝過去。
7、由于部分虛擬機的數據盤很大,而數據很少。這種情況就可以直接導出數據,然后新建一個虛擬磁盤,最后將導出的數據拷貝至新建的虛擬磁盤中即可。
統計了一下整個存儲中虛擬機的數量,整個存儲中大約有200臺虛擬機。目前的情況只能通過上述方式將恢復出來的虛擬機一臺一臺的恢復到用戶的ESXI中。
總結:
所有磁盤壞道的規律如下表:
北亞企安數據恢復——存儲數據恢復
經過分析后得到關于壞道的規則表現:
-除去SN:YHJ6LEUD上的一個自然壞道外,其余壞道均分布于RAID6的Q校驗塊中。
-壞道區域多數表現為完整的256個扇區,正好是當時創建RAID6時的一個完整RAID塊大小。
-活動區域表現為壞道,非活動區域壞道有可能不出現,如熱備盤,由于上線不足10%,所以壞道數量就比其他在線盤少。
-其他非Q校驗區域完好,無任何故障。
結論:通過上述壞道規則表現可推斷:壞道為控制器生成Q校驗,向硬盤下達IO指令時,可能表現為非標指令,硬盤內部處理異常,導致出現規律性壞道。
存儲故障是由壞道引起的,導致恢復出來的數據有部分破壞,但不影響整體,結果也在可接受范圍內。
審核編輯 黃宇
-
服務器
+關注
關注
12文章
9329瀏覽量
86131 -
數據恢復
+關注
關注
10文章
587瀏覽量
17662 -
RAID6
+關注
關注
0文章
9瀏覽量
5943
發布評論請先 登錄
相關推薦
服務器數據恢復—異常斷電導致linux系統無法啟動的數據恢復案例
虛擬機數據恢復—異常斷電導致XenServer虛擬機不可用的數據恢復案例
![虛擬機<b class='flag-5'>數據</b><b class='flag-5'>恢復</b>—<b class='flag-5'>異常</b><b class='flag-5'>斷電導致</b>XenServer虛擬機不可用的<b class='flag-5'>數據</b><b class='flag-5'>恢復</b>案例](https://file1.elecfans.com/web2/M00/8F/99/wKgaomTQm3qAf9x-AATepdcm3zE240.png)
服務器數據恢復—異常斷電導致RAID信息丟失的數據恢復案例
服務器數據恢復—異常斷電導致虛擬機配置文件丟失的數據恢復案例
![<b class='flag-5'>服務器</b><b class='flag-5'>數據</b><b class='flag-5'>恢復</b>—<b class='flag-5'>異常</b><b class='flag-5'>斷電導致</b>虛擬機配置文件丟失的<b class='flag-5'>數據</b><b class='flag-5'>恢復</b>案例](https://file.elecfans.com/web2/M00/A8/14/pYYBAGRvGYiADFTzAAU7mrFVkPI702.png)
服務器數據恢復—EMC存儲中雙循環riad5陣列數據恢復案例
服務器數據恢復—VMware虛擬機無法啟動的數據恢復案例
服務器數據恢復—異常斷電導致RAID管理信息丟失的數據恢復案例
服務器數據恢復—異常斷電導致服務器raid卡硬件損壞的數據恢復案例
服務器數據恢復-異常斷電導致服務器故障的數據恢復案例
![<b class='flag-5'>服務器</b><b class='flag-5'>數據</b><b class='flag-5'>恢復</b>-<b class='flag-5'>異常</b><b class='flag-5'>斷電導致</b><b class='flag-5'>服務器</b>故障的<b class='flag-5'>數據</b><b class='flag-5'>恢復</b>案例](https://file1.elecfans.com/web2/M00/C2/C2/wKgaomXe3RKAB9LAAAGGXQmfEy8104.png)
評論