RAID磁碟陣列資料救援案例

故障原因

客戶之前有先來電詢問，過了數天後下午17點約近十人來店送件檢測，說已送一間同行無法救援，想作急件檢測隔天中午報價，經檢測後發現有二顆硬碟皆有部份磁頭故障不良情況，由於此二顆硬碟型號為ST1200MM0159 1.2TB EXOS 10E2400系列，皆為EMC 專用SAS硬碟，Block非一般常見的512Bytes，而為了校驗資料正確性及糾錯，Block採用520 bytes，就算硬碟無損壞,硬碟接上市面大部份的SAS卡或硬碟救援鏡相工具皆無法辨識到硬碟型號容量及作鏡相磁區作業，須以特殊救援工具才能作轉換救援處理。當天客戶同意救援後先鏡相好的磁頭磁區，隔天立刻再開盤換頭讀取最後一個磁頭，但第一顆因有刮傷無法再完整鏡相，只好當天再處理第二顆損壞硬碟，此顆硬碟隔天即鏡相非常完整，後續客戶立即再提供鏡相備份對拷碟，分別鏡相對拷後交件，最後在客戶眾人的加班努力下，終讓機台可以順利上線運行恢復客戶資料. 

故障原因

客戶藍洋系統廠商幫客戶代送一組IBM System Storage DS4200 型号為1814-7VA,內部共裝了16顆IBM 500GB企業版硬碟, 共分別設定了二組RAID5, 一組4顆建構,另一組為12顆所建構,經內湖某資深救援公司處理多日後無法救援, 客戶再轉送至本公司作救援處理, 送件至本公司12顆硬碟已有4顆硬碟被開盤處理過, 但檢測此4顆硬碟,只有11號硬碟為軔體故障問題,10號硬碟有2格壞軌, 另二顆硬碟則無壞軌問題,由於有二組陣列16顆硬碟須分別鏡相對拷及分析參數重建導出資料,約經一星期左右,通知客戶進行遠端資料驗收,驗收後客戶發現尚有一個資料夾有短少情況, 經工程師再分析應有硬碟有提前離線或運行過程中離線問題, 須再分析找出再加以剔除, 剔除後再SCAN分析終於找到客戶指定資料, 共計花費了16個工作天救援完成此一案例.

故障原因

豐星管理顧問有限公司QNAP TS-831XU-RP主機內裝了8顆WD4002FYYZ 4TB企業版硬碟建講一組RAID6陣列, 送內湖資深救援公司救援一個月左右,無法救援後再送來本公司二救, 分析此組陣列應是故障後有執行rebuild動作,前方分區表的資訊多己不見,將所有硬碟導入重組陣列, 大部份的檔案也多是損壞, 懷疑有硬碟有提前離線問題,由於RAID6可以容錯2顆故障, 所以一一剔除二顆硬碟, 分析不同排列的陣列組合,終找到一組資料完整無損的組合, 由於客戶資料量多, 且陣列前面可能rebuild過程出錯,造成部份資料有錯亂損壞,所以導出資料後再使用我們的過濾破損檔案軟體, 約花2,3天把客戶損壞的檔案過濾並刪除,客戶回簽同意救援至通知驗收資料約共花13天,成功交付給客戶4.5TB完整的流水檔資料.

故障原因

TGI Friday星期五餐廳有一組 HP TGIFNT SERVER主機，由3顆硬碟所建構，設定RAID 5組態，為HP特有的雙效驗陣列。2016年某日曾送內湖某資深救援公司處理，但因處理許久無法救援，所以送來本公司作二次救援。

經工程師檢測，發現1號硬碟已被開盤，有少量壞軌故障，2號及3號硬碟皆敲盤異音有磁頭故障問題，客戶同意救援後，一一開盤排除故障並完成磁區鏡相。工程師在分析後發現1號及3號硬碟前方磁區內容不同，但後方90%磁區內容卻跟第一顆硬碟的內容相同，是十分少見的情況，新換上的REBUILD空硬碟前面磁區也有寫入資訊，細問客戶配合服務的廠商，原來廠商換上一顆新的硬碟嘗試REBUILD，但因不明原因，資料後來寫入至第三顆硬碟中，但後來也出錯故障，所以才送修資料救援，由於磁區損壞也相當嚴重，工程師一一修復處理，救援完成後，經客戶各部門人員來本公司驗收評估，順利取回資料，成功完成此一RAID 5磁碟陣列資料救援案例。

故障原因

台北影業某日主機由LSI 9261-8i raid卡建構的raid5 磁碟陣列系統CRASH，經人介紹先至某一資深同業救援處理，可能緊急需要救援，尚未將所有硬碟作好鏡相對拷動作，即嘗試將5號硬碟強制on line，再替換SLOT 6一顆硬碟去取代3號硬碟作rebuild的動作，結果rebuild完成後，分區已出現”raw”資訊，系統格式也變成GPT格式，宣告無法救援, 當天下午客戶立即再送來本公司救援。當天即動用8組對拷機台先行將所有硬碟作好鏡相工作，完成所有硬碟鏡相已近晚上十點，當晚工程師繼續加班至凌晨，分析陣列參數直接導入建構，無法還原原始陣列資料，疑似分區資訊有受損，手工再一一虛擬對應還原，共還原救出客戶3TB的資料。由於資料大多是影片原始檔及後製檔案等特殊格式，客戶自備主機來公司一一驗收，經驗收無誤後順利完成此一RAID5磁碟陣列的資料救援任務。

故障原因

新竹林先生一組群輝NAS主機, 原本設定RAID5組態, 共裝了4顆1TB硬碟,後來再新增一顆硬碟, 改設定為RAID6,在運轉重建過程中因主機過載燒毀而無法開機使用, 客戶送一家十多年救援經驗的同行,救援多日無法救援後再送來本公司作二救, 經工程師分析共有二顆硬碟有壞軌不良故障,但陣列組態應已完成RAID6轉換,且此組陣列為BTRFS系統格式,故救援難度比一般EXT或XFS系統案件高, 客戶同意救援後,約花了4天成功救援出客戶資料.

故障原因

此Raid 5由10顆IBM 74GB SCSI建構而成,原有二顆硬碟Fail造成故障.工程師作分析各顆硬碟磁區資料,發現Raid Config錯亂破損,第九顆資料嚴重錯亂,第二、八顆資料內容竟是一樣,再跟客戶進一步確認,原來事後有作過Rebuild動作,跑完三小時後雖出現OK訊息,但卻造成另二顆硬碟亮紅燈.再取回Rebuild前那二顆故障硬碟,作好鏡相後,順利於下午分析重建出陣列架構,立即導出SQL資料後製作檔案清單交付客戶,客戶派員前來驗收無誤後,成功完成救援。

故障原因

老客戶開設的系統公司, 幫客戶建構大型的影片相片資料庫, 由16顆 WD 6TB金標硬碟所建構, 設定RAID6組態, 為Windows Ntfs系統格式,某一天機台RAID組態突然不見, 工程師重新加載組態重新運行REBUILD了數天,後來發現可能會有問題立刻中斷重建, 重新開機後可以看到第一分區,但所有資料已經不見,所以送來作資料救援, 經工程師檢測分析陣列相關參數, 發現原始陣列組態中的硬碟排序跟後來設定的已不同,已造成部份資料已錯亂.最後導入正確分析參數, 交付客戶OK沒有破損的資料,順利完成此一資料救援案例.

故障原因

客戶一台JCNET NAS主機由8顆WD 750GB硬碟去建構，設定RAID5組態，客戶描述ping得到，網路芳鄰不過，請機房直接拔電源重開機二次無效，請NAS原廠修復RAID，但RAID狀態顯示not ready，客戶再送內湖資料救援同行處理約一週，但資料救援出有九成是無法使用的, 另一成皆多是破損的圖片, 對方表示有可能是資料有覆蓋的情況, 所以救援失敗再送來本公司作第二次的救援，經工程師檢測，1、2、3號硬碟各有1~3sec磁區訊號不良，但應不影響資料，分析陣列參數直接導入無法直接對應出客戶的任何資料，再作剔碟的交叉測試，發現有一顆硬碟有提前離線的問題，另此組陣列最難之處是在於是很特殊少見的RFS系統格式，非一 般的陣列處理方式可完善，客戶同意救援後，只花一天時間即成功救援並對應出完整架構，並立即通知客戶前來驗收指定45GB的資料，因客戶總資料量2.4TB，待客準備3TB資料碟備份後才成功完成此一特殊RFS系統的RAID5資料救援案件。

故障原因

某日客戶來電說他們公司杜拜廠目前有一組HP RAID 5陣列CRASH須救援,此陣列為該公司數百人共用的資料庫, 由8顆1TB硬碟所建構, 1顆作HOTSPARE,陣列總容量為6TB, 資料的儲存量約有5.2TB, 客戶先行跟我們聯絡告知準備, 走TNT國際快遞,經新加坡約6天左右總算到了台灣, 由於案件資料緊急且所有硬碟皆無嚴重故障問題, 經客戶同意直接分析各顆硬碟磁區相關參數 ,送件隔天立即分析出陣列參數並開始重建copy資料, copy過程每天不斷有公司各部門來電要求,先提取部份急用資料,由於部份硬碟磁區並不穩定, 尚有少量資料因壞軌而無法抓取對應, 所以完成第一階段資料複製作業後,再針對所有硬碟作鏡相對拷排除壞軌問題, 重建再倒回客戶重新建構的8TB HP伺服器中, 最後終完成此一海外磁碟陣列救援案例。

故障原因

台北石牌榮總心導管室一些醫學攝影資料，存放在一組16顆WD 2TB建構的陣列中，2顆作HOTSPARE，有一顆當初建構時即測試而離線，另有九顆建構成16TB的空間。某日陣列CRASH無法運行，來電本公司後，由二名工程師至現場拆下所有硬碟取回公司進行檢測，經檢測共有一顆硬碟壞軌，4顆硬碟模組損毀，當天取回後立即動用8組對拷機台，於第二天晚上終於鏡相完成所有硬碟，當晚工程師並加班分析此組陣列參數，於隔天早上順利導入重建，並提取部份資料先請客戶至專用醫療機台上測試播放，驗證是否參數運算有誤或早有1顆硬碟離線多日，經驗證無誤並經客戶同意後，即開始COPY資料，順利完成此一RAID5磁碟陣列資料救援案例。

故障原因

雪山隧道坪林行控中心多人共用一台HP SERVER，型號為HP Proliant DL100 G2，由4顆250GB硬碟建構RAID5而成，RAID卡型號為Adaptec 2420，經檢測一號硬碟馬達時有運轉異音，四號硬碟有壞軌，固件模組損壞，第二分區的分區表資訊損壞須修正補回，經工程師分析重建陣列後，順利交付客戶資料，完成此一RAID5磁碟陣列救援案例。

故障原因

桃園炬曜廣告某日來電公司一組Snake蛇吞象外接DAS故障，共有二組RAID5於前後不同時間發生故障，一組3顆及一組5顆作建構，二組皆因其中硬碟有少量壞軌而導致陣列CRASH，鏡相完成後再分別分析出此二組陣列的相關參數，導入參數順利重建陣列資料，完成此一raid救援案例。

故障原因

客戶某日來電有一台HP P2000 G3主機，共有12顆2TB SAS硬碟建構，設定RAID 6組態， 型號各是ST32000444SS、ST2000NM001、ST2000NM0023，並且內部共設定了9個LUN，升級FIREWARE時出錯故障，資料非常急用，經客戶同意，所有SAS硬碟作初步檢測，只有5號硬碟有少量壞軌情況，此12顆硬碟先不作對拷鏡相，直接分析陣列參數，送來4-5小時立即通知客戶已分析出陣列參數，並有對應到客戶部份資料，客戶同意救援後，於隔天快速交付客戶3TB的資料，由於此組陣列當時內部有許多虛擬機檔案，虛擬機內部又有許多SQL檔案，所以又免費協助客戶作後續虛擬機救援處理，最後終完成此一RAID 6磁碟陣列資料救援案例。
 

故障原因

嘉義環保局某日來電, 局內一台IBM 伺服器因RAID卡故障, 造成整個陣列Crash 無法運行, 此陣列由四顆 IBM 34GB的 SCSI硬碟所建構完成, 處理數日一樣無法還原陣列資料, 後經郵局送來本公司檢測, 發現硬碟並無任何故障或壞軌, 主因為RAID CONFIG遺失,客戶事後也沒有作過任何Rebuild或同步化等動作, 資料應可完整回復. 所有硬碟完成鏡相後, 經工程師手工分析陣列相關參數, 發現為一少見的右走向的 RAID5陣列, 並且陣列Stripe size值也非為原廠內定值, 導入參數重建此一陣列, 於客戶送件的隔天立即回報可救援出該陣列內40GB的資料, 客戶跑完成公家機關送件程序後成功完成此一資料救援案例。

故障原因

同行客戶一組SERVER 4U的伺服器主機，內共裝了16顆WD、SEAGATE、日立 1TB硬碟，設定RAID6組態，為LINUX EXT系統格式，某日陣列主機故障無法運行，從主機端記錄看4、6、8號此三顆硬碟有亮燈報錯，同行客戶無法從主機端作救援處理，所以轉送來本公司作後續救援，經工程師檢測硬碟皆無任何壞軌故障，有可能綠標硬碟節能省電功能造成休眠模式下，馬達起轉來不及加入運行或有過熱離線問題，16號硬碟磁區皆無任何資料，有可能是HOT-SPARE硬碟或沒有設定加入運行，直接分析陣列參數及硬碟順序，導入參數重建資料，只有看到二個2012年的資料夾，近期的資料皆沒有看到，應有1或2顆硬碟多年前就離線了，必須要找出並剔除後再重建，才能得到完整正確的資料，RAID6若須剔盤難度就比RAID5高出許多，因為剔除組合太多，各別單獨剔掉15顆就有15個組合，同時剔除二顆的組合更多，最後終於花了一天的時間，比對找出最完整正確的資料，順利完成此一RAID6 磁碟陣列救援案例。

故障原因

錦鈺有限公司一台 D-LINK DNS-343的NAS主機，某日一號硬碟故障後，操作人員誤操作，執行了格式化FORMAT，些許時間後發現不對立即關機，後再送來本公司進行檢測救援，經工程師檢測，一號硬碟壞軌故障，2號的磁頭不穩定，RAID CONFIG遺失，內有2顆硬碟前面分區資訊疑遭格式化，原EXT3系統格式變更為EXT2格式，直接導入分析的陣列參數無法直接重建陣列還原資料，最終各自剔除此二顆硬碟作缺盤分析重建，分別交付客戶二組陣列資料再作後續資料整理，最後終完成此一RAID 5磁碟陣列的資料救援案例。

故障原因

我愛傳媒負責FHM及CARNEWS等雜誌攝影編輯等業務，此組Raid5陣列由4顆WD黑標2TB硬碟建構而成，採用MAC HFS+格式以方便編輯剪輯。曾送某家資料救援同業再送至本公司，經工程師檢測發現第2、4顆硬碟PCB故障，須先排除硬碟硬體的故障問題，才能做後續處理。第一天先用4組對拷機台鏡相對拷此8TB硬碟，第二天工程師立即分析出陣列相關參數導入重建，由於硬碟壞軌，故障後也無作任何Rebuild或初始化的修復性動作，所以資料幾乎無破損情況，成功完成救援。

故障原因

劉先生某日自家使用的QNAP TS-459 PRO NAS--由4顆Seagate 1TB企業版建構RAID5，原本4號硬碟因壞軌故障亮燈警示，自行拆下另三顆硬碟，通電開機後重新再裝上原三顆硬碟試著運行，但始終無法進入系統而致整個RAID5陣列CRASH，來電本公司詢問了解相關檢測報價流程後，寄送至公司處理，當天完成鏡相後開始分析陣列參數，隔天即完成救援。跟一般RAID5陣列參數少見的是，第三顆硬碟的START HEAD SECTOR跟其他顆不同，偏移了6個SECTOR，詢問客戶了解可能原因，原來客戶此四顆硬碟皆在不同時間作過替換重建動作，所以可能造成此一分區START HEAD SECTOR在不同磁區的情況發生。

故障原因

客戶一台WD 原廠的NAS主機，型號為WD8000A4NC-00，內裝了4顆WD 2TB硬碟，設定RAID5組態，某日客戶無法藉由區域網路連上硬碟，有送原廠作初步的檢測，初判為連結路徑遺失，無法讀取資料，所以送來本公司救援，經工程師檢測，發現2號硬碟為壞軌故障，3號硬碟有7個軔體模塊損毀但無壞軌，4號硬碟13個軔體模塊損毀，5號磁頭後方磁區壞軌數量多，將所有硬碟完成鏡相對拷後，分析陣列相關參數，導入重建陣列順利救援客戶重要資料，完成此一WD NAS資料救援案例。

故障原因

伍豐科技公司一台色卡司的NAS主機，由5顆SEAGATE 1TB硬碟建構RAID5組態，某日發現第3顆亮燈後，再開機發現第5顆硬碟也亮燈，整個陣列CRASH無法運行，經工程師檢測後，發現卻是第1顆硬碟壞軌損毀最嚴重，第5顆少量壞軌，第3顆固件區模組損壞造成讀取速度偏慢，經工程師分析計算出陣列參數，導入重建發現近期的檔案有損毀情況，應有一顆硬碟早已離線多日，再作缺盤分析計算工程，少見的發現原第四顆硬碟雖無任何損壞，但早已脫離陣列組態離線多日了，T盤後再重建終交付客戶重要資料，完成此一RAID5磁碟陣列救援案例。

故障原因

客戶一組WD 外接式1TB行動硬碟，設定RAID 1組態，某日不明原因無法讀取行動硬碟資料。客戶使用救援軟體自行處理但無法救援出資料，經工程師檢測應是MAC電腦及WINDOWS 電腦切換時操作出錯造成分區表損毀，分析二顆硬碟分區資訊，順利導出客戶重要資料，完成此一RAID 1磁碟陣列救援案例。  

故障原因

客戶描述此台Promise Peagasus R6外接式磁碟陣列櫃，內裝了6顆WD1002FAEX 黑標1TB硬碟， 在MAC下編輯使用，原本先是一顆5號硬碟有時會出現紅燈，隔一陣子後再重新開機，可以繼續使用，接著沒有多久時間，第2顆6號硬碟也出現紅燈，也是隔一陣子重新開機，仍可以繼續使用，但再過了數天後便OFFLINE了，搜尋不到此組陣列再隔了數天後重新開機，結果第3顆硬碟也亮起紅燈了，所以只好送來作資料救援，經檢測所有硬碟皆沒有壞軌故障問題，但客戶描述的5號及6號硬碟長時間運行，會有磁區不穩定及過熱問題，皆免費鏡相處理，但3號及6號硬碟的前方分區資訊有受損，導入分析的陣列參數無法直接對應到客戶所有的分區資料，經工程師修復排除後，並一一測試找出提前離線硬碟，順利導出客戶指定資料，完成此一MAC HFS+系統的RAID5磁碟陣列資料救援案例。



 

故障原因

公司美工人員操作的主機發生了故障,多年美工人員心血結晶皆存放在此,當天下午4點多送來,工程師加班處理,隔天一早上班即回傳救援檔案清單,美工人員下午來公司驗收,發現短少部份檔案,後經確認原來此台電腦內另有二顆硬碟,桌面上連結的路徑太多,有些對應至RAID 0陣列,有些則是對應至電腦另一顆80GB硬碟中,由於另一顆硬碟並無故障,所以工程師免費幫忙將所有資料COPY整合在同一備份硬碟中.再經客戶驗收完整無誤,成功完成救援。

故障原因

客戶某日送來一台Bufflo NAS主機，客戶使用約6年左右，原第三顆硬碟磁頭已故障有異音，更換一顆全新硬碟再運行rebuild，運行許久一段時間後，第四顆也亮起紅燈無法再運作，經檢測後發現第四顆硬碟磁區後方位置有壞軌所致，鏡相處理完壞軌硬碟後，開始分析計算陣列參數，導入參數重建後完成救援。

故障原因

台中東勢資訊幫客戶系統規劃建構了RAID1陣列,某天陣列CRASH,因不小心誤操作了初始化動作,硬碟前半部MBR、DBR及部份資料已遭清空,幸好短時間立即停止操作.工程師收到件後立即檢測,硬碟除了部份模組有損壞外,並沒有什麼大問題.因硬碟內重要的關鍵磁區資料已經遭抹除,所以須手工分析重建原始的資料夾結構,最後一一對應後還原客戶原始資料, 隔天早上即成功完成救援。

故障原因

客戶自行購買2顆128GB的SSD固態硬碟，改裝設定RAID0陣列，裝入自己的SONY VAIO的筆電中，以求筆電效能提升及資料存取速度加快。某日在更新WIN7 SP1時發生錯誤無法完成更新，之後就無法開機，系統RAID 0 Crash。經送來我們公司檢測後，發現其中一顆SSD已有些BLOCK已有損壞，讀取此處即造成CRASH，工程師先後針對此二顆SSD作好鏡相工作後，即開始分析陣列相關參數，導入陣列參數重建後成功完成此一資料救援案例。 

故障原因

客戶描述：起始是家中筆電無法聯上NAS, 後來經過測試(網路及伺服器重開機), 發現2號硬碟故障, 2號硬碟換新後, 有再買一顆8TB硬碟要作備用, 同時接上4顆硬碟之後, 試著做REBUILD, 但就是呈現3號硬碟空白的狀況。經工程師檢測, 此組陣列由3顆4TB硬碟所建構, 為EXT系統格式, 設定RAID 5組態, 共有二顆硬碟有壞軌故障問題, 一顆硬碟有磁頭故障情況, 經後續開盤及壞軌鏡相處理, 成功救援出客戶指定資料。

故障原因

客戶一台華芸 AS-608T NAS主機，原本由3顆3TB及3顆4TB硬碟設定RAID5組態，後來要升級為RAID6組態，並加入了一顆新的4TB硬碟至8號位置，在組態遷移時， NAS當機一直卡在35%左右位置，只好重新啟動NAS，但原本的資料就全不見了，所以只好送修作資料救援， 經工程師檢測硬碟並無任何的壞軌故障，但分析出的硬碟順序與主機端的順序不同，由於RAID組態並未完全轉換完成，前面35%的資料須設定RAID6組態分析重建，後面65%則須設定RAID5組態，先行分析RAID6陣列參數，導出前面40%的磁區資料，此陣列難度高的部份在於後面65%的磁區資料，由於前方分區表的資訊已經變更為RAID6組態，原本RAID5組態下的分區資訊已皆不見，只能部份以猜測方式作不同組合，再掃描後面區段的流水號檔案，比對最完整的資料組合，幸客戶要的是一些影片及相片，後面RAID5導出的流水號檔案也可以接受，最後成功救援出3.3TB的資料交付給客戶，完成此一高難度且特殊的RAID5及RAID6雙組態資料救援案例。

故障原因

由二顆WD 500GB硬碟建構RAID1組態，為LINUX系統格式，原送資料救援同業處理多日，但一直未能成功救援出客戶資料。當天下午送來本公司後，工程師趕緊分析硬碟分區相關資訊，隔天中午立即通知完成並交付資料，順利完成此一RAID1磁碟陣列救援案例。