管理介面IP與帳密列表:
檔案伺服器連線方式與管理IP帳密:
用戶端連線方式: \\192.168.168.207\vol2\nas
連線IP: 第一組控制器 : 192.168.168.207
第二組控制器 : 192.168.168.214
因此可知 vol2 磁碟卷 是主要救援的目標
■ 救援分析動作
先檢視原始硬碟狀態
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/output-1-jpeg.webp)
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/1280X1280-jpg.webp)
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/1280X1280-1-jpg.webp)
▲鏡像過程中,發現有部份硬碟的狀況不好,有壞軌
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/80ea9d05-85f4-4d86-9ff3-85a8cc0554b1.png)
▲以專業的PC3000 低階硬碟資料工具,檢視硬碟的壞軌情況。
分析後,發現硬碟中,狀況極差的有: 1 & 3
因此第一次 mount 時,先把 disk 3 offline
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/078750bc-a996-4516-85a3-3939b1cb05d2-jpeg.webp)
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/0dee9d13-1ac8-4efc-940c-6f6a7be68f42-1-jpg.webp)
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/3ba064e2-6fec-43e3-a61b-b35063311d21-jpeg.webp)
上線 missing
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/330aedff-106a-45e3-a4ba-8fff4f4098d4-jpeg.webp)
■ 救援分析結論
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/2e0943a6-b14f-453d-9e84-dc896bd21fd2-jpg.webp)
因此可分析出,aggregates (aggr0) 的紀錄那邊,那1.37TB的空間是有被佔用,而volumes的紀錄,原先預期應該有vol0 和 vol2 兩個磁碟卷宗,檢測研判可能因為硬碟壞軌,而導致 vol2 的磁區資訊無法正常顯示。經查看硬碟扇區,發現vol2 區有資料存在,如下圖紅框所示
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/123-2-jpeg.webp)
![](https://www.osslab.com.tw/wp-content/uploads/2024/01/12345-jpeg.webp)
▲使用專業RAID組合軟體查看底層扇區依稀有發現vol2蹤跡
■ 以控制器救援作法
救援目標,嘗試將 vol2 所佔用的磁碟區導出,或嘗試修復 vol2的檔頭辨識區 (magic number),讓系統可以抓到該磁碟卷宗。若無法修復,就得透過掃描重組的方式,嘗試將資料導出,先將原硬碟狀態先做鏡像。
目前已知, disk1 、disk3硬碟有嚴重壞軌,則disk0在機器上顯示有故障狀況,在Aggregate 介面中,硬碟資訊有顯示重新建構(reconstrust)中,因擔憂壞軌導致vol2遺失,故將原始12顆硬碟資料倒回原硬碟,以及嘗試使用同型號硬碟將上述嚴重壞軌硬碟替換掉,以驗證是否能掛載並使用搜索方式將vol2做數據恢復,或使用使用專業數據恢復軟體重新組合RAID後將資料導出。
此方法失敗