T3B muti-disks disable, 資料無法順利使用

vincentlin

目前有座 T3B Storage, 日前因為 u1d02 被 disable,換了一顆disk 更換,此時 volume reconstruction 順利運作,但是在即將完成之際 94%,竟然 u1d05 這顆disk 也跟著備disable, 所以變成T3B的 reconstruction 還沒做完,又有另一顆 disk 也被disable 了,所以現在 T3B volume v0 是 unmount 的狀態,在 Solaris 裡 access directory 時,會出現 I/O error 的錯誤訊息!
想請教各位如何將資料(volume)救回來?

bear

难。
你的硬盘可能不少都处于临界状态了，重构的大量读写会导致再次坏盘，对于已经降级的RAID5卷，就丢数据了。你换盘前没备份么？你没看SPARE盘是否顶上去了么？

vincentlin

1.NO Hot spare disk configured in T3B!
2.資料很大,大約有 900GB , 根本沒有其他的 T3B 可提供備份,所以根本沒做!
3.另外目前已經再測試一些方式,試圖將 volume 就回來,我想這樣資料也應該可以救回,只是想問問其他人有沒有類似的經驗遇過同樣的問題,大多是如何處理的?!

bear

关注

vincentlin

終於找到把資料就回來的方式了,有點風險,不過總比啥事也不能作要好!! 以下是我個人實作的經驗,提供給大家參考
必須是在 muti - disk 故障下,方可以做以下的動作
1. 不可以更換任何故障的 disk,保持原來的狀態,並將 T3 上面關於 volume 及 volume slice 的設定,清楚記錄下來
2. connect to T3B
3. 將 volume 打掉 > vol remove v1
4. reset T3
5. 重新 configure T3
   >vol add v1 data u1d1-8 raid 5 standby u1d9
   >sun  (password : arrayservice)
   >.vol init v1 fast
   >vol mount v1
   >volslice create s1 -s 0 -z 800GB v1
   >lun default all_lun rw

其中最重要的部份是先打掉 volume 的設定,(應該沒有人敢這樣做吧),其次是進入 T3 的特殊服務模式,將 volume 的初始化設定為 fast, 這樣就不會真正把T3 給初始化了,如此一來可保留原先的資料

lyh003473

关注，改天试一下

bear

佩服楼主，呵呵，这样是有一定风险的，不过还是GX了，收藏。
不过有个问题，你上面说你的T3B没有配置Hot spare disk 但是你的下面步骤怎么有Hot spare disk 的配置呢？
vol add v1 data u1d1-8 raid 5 standby u1d9
还有这个命令的参数意义想请你解释一下，和你原来T3B的相关参数有什么关系么？谢谢
volslice create s1 -s 0 -z 800GB v1

vincentlin

在客戶端確實沒有Hot spare 的設定, 至於我的步驟是我在公司實機測試的結果,我模擬在T3B 同時2顆 disk failed 狀況下,如何把資料救回來的測試環境,沒有十足的把握怎敢拿客戶的資料開玩笑!
volume slice 的create 必須得和舊的 slice 的大小容量相同,(甚至我連 volume name 和 volume slice name 都是相同),否則在不一樣的狀況下,將破壞原本的檔案結構,舉個例子來說,原本舊的slice 為 800GB,但是重新建立的slice 為850GB 時,在這樣的狀況下 Solaris 的UFS 結構將會完全被破壞,也就是說 inode table 將會 incorrect, file system 也因此 crash , 此時我只能仰天長歎了,等著被客戶海K吧!
volslice create [Slice Name] -s [start block No.] -z [slice size;GB or MB] [volume name]

vincentlin

在客戶端確實沒有Hot spare 的設定, 至於我的步驟是我在公司實機測試的結果,我模擬在T3B 同時2顆 disk failed 狀況下,如何把資料救回來的測試環境,沒有十足的把握怎敢拿客戶的資料開玩笑!
volume slice 的create 必須得和舊的 slice 的大小容量相同,(甚至我連 volume name 和 volume slice name 都是相同),否則在不一樣的狀況下,將破壞原本的檔案結構,舉個例子來說,原本舊的slice 為 800GB,但是重新建立的slice 為850GB 時,在這樣的狀況下 Solaris 的UFS 結構將會完全被破壞,也就是說 inode table 將會 incorrect, file system 也因此 crash , 此時我只能仰天長歎了,等著被客戶海K吧!
volslice create [Slice Name] -s [start block No.] -z [slice size;GB or MB] [volume name]

solarisboy

T3B 坏两块硬盘很难恢复的！前阵见一个客户也试过此法，但没有成功