【伺服器資料恢復】斷電導致儲存raid6陣列癱瘓的資料恢復案例
伺服器資料恢復環境:
某品牌儲存中12塊SAS硬碟組成RAID6,分成一個卷,分配給幾臺Vmware ESXI主機做共享儲存;
卷中存放一定數量的Windows虛擬機器,資料盤都是精簡模式。
伺服器儲存故障:
機房斷電後開機儲存不可用。經過管理員檢測診斷後初步判斷是斷電導致的儲存陣列癱瘓。伺服器管理員聯絡我們資料恢
復中心進行資料恢復。
伺服器儲存資料恢復過程:
1、伺服器資料恢復工程師將故障儲存的所有磁碟連線到一臺Windows Server伺服器上,故障磁碟都設為離線(只讀)狀態
,連線狀態如下圖所示:(圖中HD1-HD12為目標備份磁碟,HD13-HD24為源故障磁碟):
2、使用工具以底層方式讀取HD13-HD24的扇區時發現了大量扇區損壞,初步判斷這種硬碟的讀取機制比較獨特。
嘗試更換操作主機、HBA卡、擴充套件櫃和作業系統,但均出現相同故障。與伺服器管理員溝通後得知此控制器對磁碟其實沒有
特殊要求。
3、使用專業工具對硬碟損壞扇區的分佈規律進行檢測,結果發現:
a、損壞扇區分佈以256個扇區為單位。
b、除損壞扇區片段的起始位置不固定外,後面的損壞扇區都是以2816個扇區為間隔。所有磁碟的損壞扇區分佈如下表
(只列出前3個損壞扇區):
北亞伺服器資料恢復工程師臨時編寫小程式,跳過每塊磁碟的損壞扇區,映象完所有磁碟的資料。
伺服器儲存故障分析:
1、分析損壞扇區。
分析損壞扇區發現損壞扇區呈規律性出現:每段損壞扇區區域大小總為256;損壞扇區分佈為固定區域,每跳過11個256扇
區遇到一個壞的256扇區;損壞扇區的位置一直存在於RAID的P校驗或Q校驗區域;所有硬碟中只有10號盤中有一個自然壞
道。
2、分析分割槽大小。
對HD13、HD23、HD24的0-2扇區做分析,結果發現分割槽大小和控制器中保留的RAID資訊區域大小吻合。根據物理硬碟底
層的表現發現原儲存並未啟用儲存中常用的DA技術(520位元組扇區)。
分割槽大小如下圖(GPT分割槽表項底層表現,塗色部分表示分割槽大小,單位512位元組扇區,64bit):
3、重組RAID:
a、分析RAID結構。
儲存使用的是標準的RAID6,只需要獲取到RAID中硬碟數量以及RAID的走向就可以重組RAID。
b、分析RAID條帶大小。
整個儲存被分成一個卷分配給幾臺ESXI做共享儲存。卷的檔案系統是VMFS檔案系統,而VMFS卷中又有存放了大量的
Windows虛擬機器。Windows虛擬機器中大多使用的是NTFS檔案系統,因此可以根據NTFS中的MFT的順序分析出RAID條
帶的大小以及RAID的走向。
c、分析RAID是否存在掉線盤。
映象完所有磁碟後發現最後一塊硬碟中並沒有像其他硬碟一樣有大量的壞道,其中有大量未損壞扇區,這些未損壞扇區大多
是全0扇區,因此可以判斷這塊硬碟是熱備盤。
d、重組RAID
根據分析獲取到的RAID資訊重組RAID,重組後能看到目錄結構,但是不確定是否為最新狀態。伺服器資料恢復工程師隨機
檢測了幾個虛擬機器發現部分虛擬機器正常,初步判斷RAID中存在掉線的磁碟。依次將RAID中的每一塊磁碟踢掉,然後檢視剛
才資料異常的地方但並沒有發現問題。仔細分析底層資料發現問題不是出在RAID層面,而是出在VMFS檔案系統上。VMFS
檔案系統如果大於16TB的話會存在一些其他的記錄資訊,因此在組建RAID的時候需要跳過這些記錄資訊。再次重組RAID後
針對其中的一臺虛擬機器做驗證,發現將所有磁碟加入RIAD後這臺虛擬機器是可以啟動的,但在缺盤的情況下啟動就有問題,
因此可以判斷RAID不缺盤的狀態為最佳。
4、驗證資料:
a、驗證虛擬機器。
對較為重要的虛擬機器做驗證,發現虛擬機器大多可以開機進入登入介面;部分虛擬機器開機藍色畫面或開機檢測磁碟,使用光碟修復
後都可以啟動。
部分虛擬機器開機如下:
b、驗證資料庫。
對重要虛擬機器中的資料庫做驗證沒有發現問題,除了其中一個資料庫缺少部分資料。經過仔細核對後發現這些資料在資料庫
中本來就不存在。透過查詢master資料庫中的系統檢視,查出原來的所有資料庫資訊如下:
c、檢測整個VMFS卷是否完整。
由於虛擬機器數量很多,如果每臺都去做驗證所花費時間太長。我們對整個VMFS卷做檢測發現部分虛擬機器或虛擬機器的檔案被
破壞,列表如下:
5、恢復資料:
a、伺服器資料恢復工程師和管理員溝通了目前資料恢復的情況。管理員對幾臺重要的虛擬機器進行驗證後,使用者反饋恢復出來
的資料沒有問題。資料恢復工程師立即著手恢復所有資料。
b、準備好目標陣列,將重組的RAID資料映象到目標陣列上。然後利用工具解析整個VMFS檔案系統。由於部分虛擬機器的資料
盤很大但資料很少,可以直接匯出資料然後新建一個虛擬磁碟,最後將匯出的資料複製至新建的虛擬磁碟中即可。
c、透過上述方法將恢復出來的虛擬機器一臺一臺的恢復到使用者的ESXI中。後續的資料遷移過程中由北亞資料恢復工程師和使用者
方工程師配合完成,這裡就不贅述了。
資料恢復結果:
本案例儲存故障是由壞道引起的,最終恢復出來的資料也有部分損壞,但不影響整體資料,最終的結果也在接受範圍內。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2906693/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【伺服器資料恢復】斷電導致伺服器癱瘓的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】raid5陣列癱瘓導致儲存不可用的資料恢復案例伺服器資料恢復AI陣列
- 【伺服器資料恢復】斷電導致raid資訊丟失的磁碟陣列資料恢復案例伺服器資料恢復AI陣列
- 【伺服器資料恢復】異常斷電導致ESXI無法連線儲存的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】Hyper-V服務癱瘓的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】Raid5癱瘓導致上層lun無法使用的資料恢復案例伺服器資料恢復AI
- 【儲存資料恢復】esx vmfs的互斥導致儲存資料丟失的資料恢復案例資料恢復
- 伺服器資料恢復-V7000儲存磁碟故障導致業務中斷的資料恢復案例伺服器資料恢復
- 【北亞資料恢復】伺服器斷電導致Oracle資料庫報錯的資料恢復案例資料恢復伺服器Oracle資料庫
- 【伺服器資料恢復】浪潮伺服器硬碟壞道導致raid5癱瘓的資料恢復伺服器資料恢復硬碟AI
- 伺服器raid陣列癱瘓如何恢復伺服器資料伺服器AI陣列
- raid5磁碟陣列伺服器癱瘓資料恢復AI陣列伺服器資料恢復
- 【北亞資料恢復】伺服器raid陣列癱瘓導致ZFS檔案系統元檔案損壞的資料恢復資料恢復伺服器AI陣列
- 【raid資料恢復】光纖儲存raid陣列資料恢復案例AI資料恢復陣列
- 【伺服器資料恢復】意外斷電導致linux伺服器崩潰的資料恢復案例伺服器資料恢復Linux
- 【資料庫資料恢復】斷電導致Oracle資料庫資料丟失的資料恢復案例資料庫資料恢復Oracle
- Linux伺服器癱瘓資料恢復Linux伺服器資料恢復
- 伺服器資料恢復—V7000儲存磁碟故障導致Mdisk失效的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】HP EVA儲存資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】Hyper-V虛擬機器檔案丟失導致服務癱瘓的資料恢復案例伺服器資料恢復虛擬機
- 【儲存資料恢復】儲存上的raid5陣列崩潰的資料恢復案例資料恢復AI陣列
- 【伺服器儲存資料恢復】HP-Lefthand儲存資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】意外斷電導致RAID模組資訊丟失的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】raid6崩潰導致分割槽丟失的資料恢復案例伺服器資料恢復AI
- 【伺服器資料恢復】斷電導致伺服器無法進入系統的資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】虛擬機器檔案丟失導致Hyper-V癱瘓的資料恢復伺服器資料恢復虛擬機
- 【伺服器資料恢復】Linux環境下RAID6磁碟陣列資料恢復案例伺服器資料恢復LinuxAI陣列
- 伺服器資料恢復-斷電導致linux作業系統資料丟失的資料恢復案例伺服器資料恢復Linux作業系統
- 【北亞資料恢復】意外斷電導致戴爾伺服器raid5陣列資料丟失的資料恢復資料恢復伺服器AI陣列
- 【伺服器資料恢復】Linux伺服器癱瘓後重灌系統資料丟失的資料恢復案例伺服器資料恢復Linux
- 伺服器資料恢復成功案例(磁碟陣列恢復)伺服器資料恢復陣列
- 【伺服器資料恢復】機房意外斷電導致伺服器資料丟失的資料恢復案例探討伺服器資料恢復
- 【伺服器資料恢復】infortrend ESDS系列儲存資料恢復案例伺服器資料恢復
- 【伺服器資料恢復】斷電導致ProLiant伺服器RAID模組損壞的資料恢復案例伺服器資料恢復AI
- 【Vsan資料恢復】斷電導致Vsan分散式儲存虛擬磁碟檔案丟失的資料恢復案例資料恢復分散式
- EVA4400儲存斷電導致資料丟失如何恢復
- 【北亞伺服器資料恢復】異常斷電導致ESXI系統無法連線儲存的資料恢復伺服器資料恢復
- 【伺服器資料恢復】某品牌MSA SAN儲存資料恢復案例伺服器資料恢復