故障原因

台中一間資料庫系統服務廠商，受客戶委託代送一組企業級儲存設備進行急件檢測。設備送達後，雷德資料救援工程師立即安排當日將主機硬碟送回台北總公司進行進一步檢測與分析。本次救援設備為 DELL EMC VNX5100，共配置 30 顆 600GB SAS 硬碟，內部共包含多台VM虛擬機需要救援。本案主要難點包括：
1.EMC SAS 硬碟無法透過一般電腦或 SAS 擴充卡正常鏡像對拷。
2.硬碟磁區格式為 520 bytes/sector，須先轉換為 512 bytes/sector 才能進行後續分析。
3.陣列包含 RAID、Pool、LUN 等多層結構，重建程序相當複雜。
4.底層為 VMFS 虛擬化檔案系統，需進一步解析才能導出 VM 資料。
由於客戶端設備當時出現 Write Cache 故障，且 Pool 已呈現 OFFLINE 狀態，經評估後客戶同意進行資料救援。雷德資料救援同步從兩個方向處理：一方面進行硬體故障排查，另一方面進行硬碟鏡像、格式轉換、陣列參數分析與資料重建。硬體檢測過程中，工程師發現電源模組異常，並進一步處理 SPS A 的 Not Ready故障狀態。軟體分析救援方面，則透過多埠 SAS 鏡像設備，加速處理 30 顆 EMC SAS 硬碟的鏡像與512byte格式轉換作業。
最終，客戶同意作特急件救援, 順利在6天內完成30顆SAS硬碟鏡像對拷，並將所有硬碟轉換為 512 bytes/sector IMG 映像檔, 後續陣列參數分析重建架構與 VMFS 檔案系統解析後，成功導出兩組LUN 內的VM 虛擬機資料，並交付客戶驗收，完成此一高難度的EMC陣列資料救援案件。

故障原因

2024年，台灣曾發生一起雲端代管服務因硬碟故障而無法正常運作的重大事件。該事故導致多家承租客戶的公司 SQL 資料庫、網站系統及雲端服務受到影響，部分企業營運因此陷入停擺。本案雲端服務架構建置於 DELL EMC 主機系統上，內部使用多顆企業級 SAS 硬碟。因與一般硬碟常見的 512-byte 磁區格式不同，此類 DELL EMC 企業儲存設備採用特殊的520-byte磁區格式。即使硬碟本身未完全損壞，也無法直接透過一般主機、標準陣列卡或傳統SAS對拷設備進行鏡像複製。因此，當系統發生 RAID 故障時，必須仰賴具備專業設備與企業級儲存系統處理經驗的資料救援團隊，透過專業鏡像救援機台進行底層資料讀取與硬碟複製，才能進一步重建資料與恢復服務。本次事故於2月15日發生後，客戶先將設備送交其他資深業者處理數日，後於2月19日下午4、5點左右轉送至本公司進行檢測與評估。經了解，整台EMC主機內共有30組 RAID5 架構串接運作，其中主要故障點來自其中一組RAID5。因該組RAID5的異常導致整體雲端系統無法正常啟動，進而造成服務中斷。EMC後期非VNX系列主機, 己經很難以軟體分析參數及重建還原導出資料。進一步檢測後發現，該組 RAID5 中有兩顆 1.2TB SAS 硬碟皆存在單一磁頭故障損壞情況。客戶於隔日確認同意救援後，本公司立即針對兩顆故障SAS硬碟進行專業鏡像處理與開盤資料救援作業。在救援過程中，本公司於3天後先行交付第一顆完成鏡像的對拷硬碟給客戶，並於第4天完成第二顆故障硬碟的鏡像作業與交付。後續在原廠及配合系統廠商的共同努力下，該EMC雲端主機最終於2月27日順利恢復正常運作，成功協助客戶降低服務中斷所造成的營運損失。

故障原因

台北廖先生以CANON EOS 1DX-MARK ii拍攝MOV短片約有90部, 在機身上不小心誤按了格式化後取出, 自行使用救援軟體救出了90個影片但皆無畫面且會有破音情況, 後送了一家資料救援公司一樣無法救援處理,所以只好轉件來我們公司作二救,因各家相機或攝影機廠商所拍攝的影片皆有自己不同的編碼, 所以須經工程程比對分析處理, 後於隔天利交付客戶急用影片資料.

故障原因

台北楊先生送來一件資深同行無法救援的SSD,是由Toshiba筆電拆下, M2介面128GB, Lite-on製造, 型號為CV3-SD128, 檢測發現己經完全無法辨識到型號及容量。其SSD主控IC為88S1074-BSW2, 板上共有二片儲存資料的BGA FLASH,而我們主要的SSD救援工具PC3000 UDMA,並沒有支援此型號主控IC, 所以無法以一般常見短接電路走安全模式,再針對韌體去做修復重建,須以其他方式再作後續救援,PC3000 UDMA SSD是目前市場上最強大的SSD救援工具,但大多近一、二年生產銷售的SSD多半沒有支援,本公司己有多套不同救援方案可提供救援服務,有一半以上高難度SSD案例皆是非以PC3000救援成功的。此案件經三天工程師不斷嘗試不同救援方案救出,客戶得知資料完整度100%非常開心.

故障原因

客戶描述當時隨身碟存取檔案到一半突然故障，電腦跳出要求格式化的視窗讀不到隨身碟內的資料無法存取，送至某家資料救援同行無法救援，經本公司工程師檢測，該隨身碟為物理性故障，主控IC為SM3267L，FLASH須拆焊作資料救援手工分析運算處理。

故障原因

台東海瑞鄉客戶送一件創見512GB SSD固態硬碟至北部資深公司救援約2個月左右, 最後無法救援送來本公司處理,, 經工程師檢測磁碟管理完全抓不到型號容量,其主控IC型號為SM2263XT, 電路板上共有個BGA晶片, 經工程師處理約9天時間終完成救援, 通知客戶驗收取資料. 

故障原因

客戶描述其Microsoft 微軟Surface Pro 7 PLUS 使用約3至6個月後會出現藍白畫面, 過一段時間又正常, 但最近卻完全無法開機使用已經抓不到SSD, 後來光華商場一一詢問過許多電腦同業後再送來本公司處理, 經客戶同意後拆下其筆電中的SSD固態硬碟, 檢測後發現上電一樣無法辨識到正確的型號及容量,屬於物理性損壞故障, 而其主控IC型號為MAP12QA, 共有一片儲存資料BGA晶片, 但因為此主控IC在PC3000 SSD救援工具並沒有支援, 工程師須另以其他救援方式破解處理, 最後終成功完成此SSD救援案件.

故障原因

客戶描述他有一顆SAMSUNG T7外接式的行動SSD固態硬碟有故障, 讀取資料時當機會持續LOADING, 之後就完全讀不到了,送回原廠有讀到最後一次, 原廠作檔案拉取後再度當機, 送資深救公司回覆儲存資料晶片受損判讀無法再救援, 此客戶送來本公司前已送過三家資料救援同行,後來才送來本公司檢測救援, 由於目前全世界SSD救援工具皆不支援USB, TYPE C介面下的操作救援,故無法以一般常態救援方式處理, 由於收到時己經完全抓不到正確型號容量, 其主控IC為S4LR033, 救援工具並不支援固件操作, 共有二片BGA儲存資料晶片, 經工程師檢測客戶同意後, 開始以不同救援工具及方式去一一排除故障情況, 最終花了四天時間搶救出客戶所有資料, 完成此一高難度別家無法救援的SSD固態硬碟救援案例

故障原因

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

故障原因

Micro SD卡可以抓得到型號容量看得到資料，但接上電腦會造成當機，資料無法COPY出來，經工程師檢測為FLASH內部Block區塊損壞，須透過FLASH專用資料救援工具，作後續鏡相對拷救援。

故障原因

SanDisk 128GB USB 隨身碟 讀不到，接上電腦讀取不到磁區，送到一家台北市資深救援公司及另一家資深救援公司櫃台檢測後皆直接退件不處理，後因還是想要維修救回隨身碟資料, 故送至雷德資料救援成功救出70幾GB資料ㄝ完成此一隨身碟資料救援案例。
此案例為COB封包晶片物理性故障，須打磨拋光晶片透過機器讀取內容，再作ECC校正重讀，救援分析難度高, 須花費許多程序及時間, 成功率也不高, 所以一般同業此類案件若是電腦磁碟管理無法辨識，大多會直接現場退件。

故障原因

隨身碟接上電腦後顯示需格式化，曾送其他救援公司檢測，因報價太高轉送雷德資料救援。
主控IC為SM3267L，無法辨識正常型號及容量，FLASH須拆焊作資料救援手工分析運算處理。

故障原因

不小心折到隨身碟，完全無法焊接修復，主控IC為SM3267L，FLASH 為sandisk c612072222，經工程師拆下晶片分析相關參數，導入參數發現FLASH還是有部份BLOCK損壞，經過多次重讀才交付客戶95%資料。

故障原因

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

故障原因

小尺寸特殊規格少見的硬碟，高精密度開盤救援難度高，且有特殊型號材料不好匹配的問題，客戶描述之前可正常使用，某天出現雜異音，突然無法讀取。

故障原因

客戶描述此顆硬碟無法過電，之前送過其他資料救援公司檢測救援，因預算考量再送至本公司作二次檢測及救援，客戶主要要救援SQL資料庫的資料。

故障原因

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

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

故障原因

突然間讀取不到，電腦管理的磁碟管理抓不到此隨身碟裝置，無法辨識正常型號容量。主控IC為AU6998SN，該FLASH為SD卡規格一體COB封包晶片，須經救援工具讀取出資料後再分析FLASH相關參數救援處理，救援難度比一般FLASH晶片救援高出許多。

故障原因

1.無法讀取,裝置管理員找不到. 2.SD卡外殼破損. 3.主控IC為SM2682LT,電腦管理的磁碟管理抓不到此裝置, 無法辨識其正常型號容量FLASH須拆焊作資料救援分析運算處理.

故障原因

SanDisk隨身碟不慎摔壞，後來電源燈不會亮也讀不到資料，電腦管理的磁碟管理抓不到此隨身碟裝置，無法辨識正常型號容量，主控IC:Sandisk 20-82-00381-A0，FLASH須拆焊分析資料救援處理。

故障原因

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

故障原因

客戶送一家美國資料救援公司作救援，但因R/W讀寫磁頭故障，對方救援時間很久還是一直無法救援出任何資料，回台後再送至本公司救援，經工程師檢測該顆硬碟為4個碟片、8個磁頭，電路板為USB原生介面，須改裝SATA介面再以專業救援工具救援，另有硬體加密問題須破解, 歷經七天後救援出99.99% 客戶1點多TB的資料。

故障原因

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

故障原因

1、隨身碟經常使用皆正常，突然讀不到資料。
2、之前有稍微折到過，是否是這個原因?
送同行處理無法救援後送至本公司處理, 經檢測磁碟管理抓不到型號容量, 屬物理性損壞, 主控IC為EN3257LT，FLASH須拆焊作資料救援手工分析運算處理。

故障原因

USB隨身碟接上電腦讀不到，之前曾送一家電腦同行救援維修隨身碟，但無法救援再送來本公司救援，檢測後發現其為少見主控IC：SSS6690，分析救援難度較高，經工程師多日分析重讀，順利完成此件別家無法救援的FLASH隨身碟救援案例。
 

故障原因

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

故障原因

國立中央大學有一台半導體離子部植機用的工業電腦, 主機型號PC-9821 Xa, 由於故障壞掉不能開機, 由救援軟體雖可以看到磁區內容, 但懷疑檔頭好像不見須修復至可以開機狀態,內裝一顆NEC DSE1700A 1.7GB的IDE硬碟, 分析處理發現為日文版的DOS PC9800作業系統, FAT16格式,經檢測硬碟並無壞軌故障, 但由於己經不能開機運行,客戶無法提供原始開機系統軟碟片, 所以處理難度高,後續經工程師修復處理,再鏡相對拷一顆系統碟, 順序完成系統修復成功開機運行, 完成此一特殊機台的開機修復救援任務. 

故障原因

老客戶開設的系統公司, 幫客戶建構大型的影片相片資料庫, 由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資料救援案件。

故障原因

客戶描述發生車禍意外, 行車記錄器裡的一個檔案不見了,須要救援。此類狀況在早期的行車記錄器中常發生, 影片在車禍發生的撞擊瞬間被中斷錄影, 行車記錄器可能無法存入此檔或存入一個檔案卻無法正常播放, 由於有些行車記錄器的影片編碼不同, 所以處理的難度也大不相同, 此部份須工程師專業判斷及修復才能成功完成救援.