故障原因

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

故障原因

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

故障原因

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

故障原因

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

故障原因

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

故障原因

筆電吸到磁鐵後開始發出異聲，重新開機後打不開。

故障原因

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

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

故障原因

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

故障原因

硬碟有發出異音。經工程師檢測該顆硬碟共有4個碟片、8個磁頭，1號磁頭汙染，1號碟面有刮傷情形，經10天救援出客戶2TB多的資料。

故障原因

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

故障原因

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

故障原因

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

故障原因

使用中當機，拔傳輸線後就無法讀取硬碟。

故障原因

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

故障原因

原筆電ASUS是WIN8，後來強迫更新成WIN10，想要降回WIN8，利用網路上方法，不小心把分割磁區刪除，重灌成WIN8。

故障原因

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

故障原因

硬碟應有壞軌，目錄中所有的VM檔案讀不到，以至於VM開不起來。

故障原因

很久之前摔到硬碟，中間使用正常，今天讀取速度慢不斷讀取就壞了。

故障原因

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

故障原因

傳輸時不明原因造成檔案損毀，電腦端及攝影機都無法讀到檔案。曾自行使用檔案救援軟體，但無法救回，之後並無其他寫入動作。