引用:
|
作者MMXPro
備份、備份再備份，這是做了十多年DBA和BI的經驗，
RAID CONTROLLER壞掉在業界是很正常的事情，
若是壞了一般人是沒辦法救回資料的，
每片RAID CONTROLLER在韌體上都會寫入唯一KEY，
這不是換一張卡就可以解決的，
之前的公司，交易主機上磁帶，丟到後端的DW也上磁帶，
有一天交易主機掛了，少了一天的資料，主機的備份磁帶竟然沒COPY進去，
最後用DW的資料把資料補進去，
這是後來不做DBA搞BI(商業智慧)的原因  |
這4~5年來..
算是近代RAID f/w會操作一種OAR(RAID Roaming)的行為...
他會因為RAID controller的替換而從VD的metadata進行import的操作...
比方說LSI的RAID f/w(IMR)會預先切入512MB(per PD)左右的tail作為metadata...
假設我替換RoC(如果是IR mode則為有限的64MB)...
通常並不會因為掛了而導致VD全部救不回...
因為OAR將會復原這些操作..
(如果這種基本的競爭條件都做不到, 那些RD全部都要去填海...
...)
但是他有個附加前提..
1. 最好不要與ODR操作衝突, 因為這是metadata的不一致性情況的可能.
2. 如果先前有做過HSP操作, 也必須要注意!..因為這已經不是原來的metadata..
我相信很多MIS根本都不會想到要操作copyback這塊來復原metadata, 乖乖就把HSP當成VD的一部分操作(找死嗎??
..)... 這時HSP是一種revertable的狀態(因為連文件都不想讀, 有簽合約維護就算了. 叫廠商去死(依合約內容而定)..)...,
RAID f/w提供哪些RAID mode那根本都是basic functions...
這些設計專屬的RAID ASIC提供差異化的RAID f/w的IP廠商..
真正的重點在於它們所提供的
附加價值...
比方說之前有幾個網友來問我(居多都是對岸的案例..)..
有一個案例, 不過他是新加坡的..
他的100TB(LSI)系統掛了, VD上的48顆PD全部offline..
RAID f/w已經判斷為foreign狀態...
這不只是著急, 而是快崩潰了..
既沒有任何合約廠商來協助, 也不可能找提供RAID IP的原廠來幫忙(因為很費時..)
但是他最後的復原操作其實很簡單(良好的文件支持網站可以到intelraid尋找, 這大廠並不吝嗇, LSI的KB在1~2年前已經換掉了, 爆爛一把的. 超難用!)..
1. 判讀h/w log(不是event log, 不一樣的東西), it's very important!
2. 安全性的操作(不會破壞metadata)
3. 如果失敗, 在判讀一次h/w log
4. 確認操作一次init w/o BGI即可復原(風險較高, 通常擺在最後..)
5. PR+CC作下去, 確認可靠性
6. 然後收錢(沒收啦!..我又不幹這行..)...
有些時候只有那幾種步驟...
當然我沒有看過很多案例....
但是有些情況就只有那樣子而已..
...
我不否認有一些特殊情況...
因為實在太特殊...
跟RAID本身幾乎八竿子打不著邊...