您的當前位置:首頁 > 陣列恢複

陣列恢複Raid Restoration

            1. RAID的概述
            2. 磁盤陣列技術-術語匯編
            3. Raid卡崩潰之後的數據問題
            4. RAID1--5技術詳解
            5. 磁盤陣列技術原理學習


推薦華山劍客(王老師)做遠程陣列恢複,有需要可以直接聯係他 QQ409133413,電話:13872883452

支持RAID0重組
支持RAID5重組,包括左旋轉和右旋轉、同步和異步等不同形態的陣列。支持IBM的較為少見的不標準的右旋轉異步。
支持HP雙循環重組
支持IBM的RAID1EE和RAID5EE重組
支持跨區卷/動態分區的重組
支持非標準的右旋轉異步,第一個校驗盤不是0塊硬盤的重組
支持非標準的陣列,陣列開始位置不是0扇區的重組

完全透明的陣列重組功能,可以讓您輕鬆的恢複技術門檻較高的磁盤陣列數據。隻需設置好磁盤或者鏡像文件後便可以在內存中直接提取陣列中的目錄結構,無需做出整個陣列的鏡像。大大減少數據恢複的時間。有智能模式和專業模式2種工作模式,智能模式隻需設置磁盤(不要求磁盤順序)便能自動分析出RAID5的參數和裏麵的分區,直接加載出目錄。專業模式可以單獨設置各個參數後加載分區或者製作出陣列鏡像進行恢複。有些時候陣列是完好的情況,做出陣列的鏡像到普通硬盤再掛回服務器就可以直接啟動。 


難度較大的陣列恢複案例:

-------- 日期:2008-6-20 企業版客戶: 上海某數據恢複 -------- 陣列情況:IBM陣列,RAID5EE級別,5個SCSI硬盤組成的RAID5EE陣列,每個硬盤68g,總共200g左右數據。該5EE是左旋轉的,不常見,分析數據分別規律後,升級了軟件就支持了,這個陣列分區表損壞了,通過腳本編程掃描出分區的DBR位置,然後虛擬卷加載出目錄。該陣列裏麵居然分了23個分區,每個分區都是9g左右小分區,存放的是教材資料,數據完全恢複,就是虛擬加載23個分區比較辛苦。

-------- 日期:2008-6-19 企業版客戶: 北京某數據恢複 -------- 陣列情況:4個250g的sata硬盤組成的陣列,類型不詳。分析了4個硬盤的數據,發現前麵有個FAT32分區,隻是DBR顯示出這個分區是1T的,的技術人員斷定這個dbr有問題,一般Windows服務器陣列的分區是NTFS的,就用數據恢複大師軟件裏麵的腳本編程的功能來掃描4個硬盤的關鍵數據區域,找了10多分鍾沒找到一丁點NTFS分區的數據信息。重新研究了這個FAT32的DBR,1T的DBR還沒見過呢,如果這個DBR是正確的,那麽4個250g盤的組成的陣列隻能是RAID0或者跨區卷了。根據FAT32的FAT,FDT信息很容易排除RAID0陣列的可能性,剩下來的隻有跨區卷了。嚐試了 1,2,3,4 的磁盤順序,用數據恢複大師跨區卷組合了下,發現有些目錄丟失,找到的文件有一部分可以打開,這應該是參數沒設置對。在數據恢複大師軟件裏麵的列表視圖裏,挑選了幾個比較大的文件開始簇號,根據DBR的信息和開始簇號,直接計算出這些文件在陣列中分部在第幾號硬盤上某扇區的位置,然後在3個硬盤中用腳本編程的方式查找該位置附近的文件頭,根據匹配的文件頭來確定該硬盤是第幾號硬盤,從而確定出硬盤順序。確定好參數後再次組合出來的目錄非常完整,文件能完全恢複出來。該跨區卷的難度在於磁盤順序以及跨區卷在磁盤上的範圍確定起來有點難度,而且1T這麽大的FAT32分區的技術人員也是第一次碰到,開始還不相信,忽略了它來找NTFS分區,繞了個圈子,還好及時回過來分析被忽略的FAT32分區,完美的恢複出數據。

-------- 日期:2008-4-10 企業版客戶: 山東某數據恢複 -------- 陣列情況:IBM陣列,RAID5EE級別,SAS接口的6個盤,每個盤136g,陣列容量136×4g(RAID5EE有2個盤的冗餘,所以這個陣列隻有4個盤的容量),3個分區,數據主要在D,E分區。企業版客戶用轉接口接上硬盤,作出鏡像後,簡單的分析磁盤順序和塊大小後發現這個陣列的分區表完全損壞,第一個分區前麵基本被清空,有一個磁盤掉線過,不過掉線時間不長。用最新的2.71版本就設置好IBM RAID5EE磁盤和塊大小,保存好陣列信息,用腳本掃描很快定位到第2個分區和第3個分區的邏輯開始扇區位置,配合虛擬卷的功能很快就列出目錄結構,把裏麵的壓縮包和工程製圖導出幾十M檢查,導出的文件能完全打開,確定重組正確後開始大量導出全部目錄,後麵2個分區的數據完全恢複。這次遠程恢複比較順利,從分析參數到開始導出目錄僅僅耗時20分鍾左右,比起前幾次分析RAID 5EE的案例少了不少時間。

-------- 日期:2008-2-23 企業版客戶: 湖南億嘉數據恢複中心 -------- 陣列情況:IBM陣列,3個盤,每個盤68g,3個分區,數據主要在D分區,Oracle數據庫。最初是卡壞,用戶便找了一個IBM的卡,把3個盤掛上去,一番搗鼓之後,係統盤C可以引導啟動係統了,但是D,E分區丟失。在服務器上嚐試多種數據恢複工具掃描整個硬盤,均可發現D、E分區的目錄文件,但是恢複後大的文件無法打開。通過遠程協助的方式,分別對3個盤的扇區進行分析,發現C盤和後麵2個分區的數據排列形式居然不一樣,因此斷定客戶替帶陣列卡和原卡有差異,必須通過重組進行恢複。該陣列C分區的參數是右旋轉異步,第一個校驗盤0;後麵2個分區的參數是右旋轉異步,第一個校驗盤1,用這個參數在數據恢複大師軟件裏麵設置好以後通過虛擬卷的方式直接加載出D、E分區,目錄文件完整,數據庫也無損打開。一般說來,同一個陣列裏麵不會出現不同排列情況的數據,可為何C盤的數據排列和後麵2個盤不一樣呢?推測新卡替代後,客戶當時並不能直接引導C盤啟動係統,他們用修複光盤把係統修複啟動才能啟動的,在修複的過程中把C盤的係統文件都重新複製了一遍。幸好沒有破壞到後麵2個分區數據。由此可見數據丟失後千萬別亂恢複,不然很容易破壞數據,增加恢複的難度。

-------- 日期:2008-1-31 企業版客戶: 上海某數據恢複 -------- 陣列情況:HP陣列,3個盤,每個盤68g,3個分區,數據主要在D分區,重做係統後D,E分區的數據庫文件以及備份丟失。通過遠程協助分析陣列數據後發現,客戶的D盤裏麵大部分文件已經被刪除,E盤則是在前天剛剛新格式化的(分區的創建日期可以通過磁盤記錄分析出來的),陣列的塊大小是16K,開始扇區是1088,標準的HP雙循環陣列。通過的數據恢複軟件,直接重組後,用虛擬卷的方式加載出D,E分區,然後設定掃描範圍,集中掃描了文件記錄所在的扇區,裏麵的數據庫和大的平麵圖片都恢複出來,17M的jpg圖片可以無損打開,數據庫也能附加到數據庫中。-------- 日期:2008-1-30 企業版客戶: 天津鴻萌數據恢複 -------- 陣列情況:IBM RAID5EE的陣列,4個盤,每個盤73g,硬盤掉線,隻做出1,2,4號盤鏡像,3號盤壞道嚴重無法製作鏡像。通過QQ遠程協助後確認了此陣列的磁盤順序未 1,2,X,4,以及塊大小,使用DataExplore數據恢複大師企業版2.55的版本的陣列功能設置好陣列參數後直接加載出裏麵的4個分區,目錄文件完全正確,數據100%恢複。

-------- 日期:2008-1-12 企業版客戶: 成都某數據恢複 -------- 陣列情況:IBM RAID5EE的陣列,6個盤,總共4個分區,每個盤73G,其中2,5硬盤掉線,導致數據分區無法打開,客戶將6個硬盤掛入另外一個同型號的陣列卡完成配置後,服務器無法看到陣列裏麵的分區,再把硬盤掛回原來的陣列,發現分區丟了2個,而且能看到的係統分區也無法打開。通過QQ遠程協助,發現陣列的係統分區(第一個分區)已經破壞比較嚴重了,分析後麵的數據區發現3,5號盤順序反了,估計是客戶插拔硬盤中搞錯了順序。將磁盤順序和塊大小設置好後,去掉2個掉線的硬盤恢複出數據區裏麵的數據庫(5EE的陣列可以缺少2個硬盤來恢複數據的)。

-------- 日期:2008-1-5 企業版客戶: 長春怡足數據恢複 -------- 陣列情況:8個750G盤組成的陣列,陣列卡型號不詳,NTFS單個分區5T,裏麵有3.8T的數據。經過該中心工程師的細致分析,確定了盤序和塊大小等基本參數,但使用常規軟件無法恢複出數據結構,最後使用軟件左旋轉+異步功能,列出分區和目錄就直接導出數據了。因為分區大於4T,普通的32位的WINDOWS應用程序無法支持那麽大的陣列,該中心又緊急聯係升級了企業版軟件,使軟件支持64位的係統後才完全恢複出全部數據。

-------- 日期:2007年12月 企業版客戶:北京某數據恢複 -------- 陣列情況:4個硬盤組成的跨區卷其中2個硬盤是146G,2個硬盤是68G,數據丟失的原因不詳,硬盤順序不詳。通過遠程協助的方式,分析出2個68G的硬盤屬於1,2號盤,另外2個146G的硬盤屬於3,4號盤。因為是係統軟件做出的跨區卷,每個硬盤均從63扇區開始,但是結束扇區無法直接得出,通過手工計算以及軟件裏麵的腳本分析功能才確定出每個硬盤實際在跨區裏麵的具體扇區數量,確定好參數後,使用企業版軟件的跨區卷功能來虛擬加載出這個分區,數據完全恢複。

-------- 日期:2007年10月-11月 浙江湖州紹興寧波電信-------- 陣列情況:3個地區的電信10000號服務器出現故障,造成大量的10000號電話錄音文件丟失。湖州電信的錄音文件所在的D分區無法打開(提示需要格式化),用戶插入陣列卡自帶的光盤後自動做了rebuilding操作。用數據恢複大師軟件直接在他們服務器上檢查了一下,發現是分區目錄文件損壞,直接用企業版的軟件,虛擬加載的方式直接加載出D盤後掃描文件記錄所在的扇區,掃描了半個多鍾頭後列出所有的錄音文件目錄文件,大約620G數據,通過映射網絡驅動器的方式直接恢複到其他服務器上,大部分錄音文件可以播放。紹興和寧波的服務器均是硬盤掉線,陣列無法讀寫,帶上SCSI卡接上硬盤,分析出掉線過後無數據的硬盤後以虛擬重組的方式提取出數據,數據均通過網絡驅動器的方式恢複到別的硬盤上。其中紹興的服務器數據量達到1.9T,導出數據耗時將近一周。