以一起資料災難談RAID0+1及RAID1+0
近日,遇到一例4塊盤SCSI RAID0+1的資料恢復,由4塊36G SCSI組成。客戶稱是做了兩組RAID1。出故障後,RAID狀態裡3塊盤OFFLINE。
按我的理解,這個應該是兩組邏輯盤(分別做的RAID1),那即使是3塊盤OFFLINE,也應該有一組邏輯盤是可以正常工作的。但客戶用裝在別的硬碟上的WINDOWS訪問此陣列時,也無法識別陣列的邏輯盤。這樣的話,很多就解釋不通了,只能仔細分析了。
拿下硬碟,單獨接在SCSI介面卡上,進入系統,無異常,可以識別出4塊物理硬碟。分析,無明顯RAID資訊區域,之後,對4塊盤做比較,結論是1、3號盤及2、4號盤每組都有相同性,但後面有大量不一致資料。1號盤及2號盤裡有分割槽表,每個分割槽表裡的描述都大約指出原邏輯盤分割槽總和大約68G。據此,可知有以下三種情況:
1、兩組RAID0,但1、3號及2、4號均有部分完全相同的資料,應該可以排除。
2、RAID1+0(即兩兩做RAID1,再做RAID0,這種安全級別高,客戶是整合商做的,可能性最大),一段時間內,兩組RAID1中先後都有一塊硬碟離線(此後就相當於RAID0,再不能提供任何冗餘)。再後來,又有一塊硬碟離線,系統崩潰。這種情況非常符合RAID裡的表現。
3、RAID0+1(即兩兩做RAID0,再做RAID1,這種不太好,推斷可能性不大)
根據分析後,發現除1、3組成的RAID,無任何錯誤,認為應該是對了。重組資料。直接寫回RAID,系統正常可以啟動。檔案訪問也正常。
本來以為已經完美解決了。結果很短的時間內收到客戶電話,稱資料嚴重滯後,是兩年前的東西。
一細想,大悟。
真實的情況應該是:使用者做了RAID0+1,結果組成RAID1中的其中一組RAID0中有一塊盤離線(應該為1或3),導致整個RAID0離線(兩塊離線了),之後一直以單RAID0的方式工作(想起來竟然兩年有餘,汗!),直到最近,剩下的一組RAID0中有一塊盤離線,RAID徹底癱瘓。使用者使用的RAID卡為ADAPTEC的0通道RAID卡,比較低端,無法安全緩衝資料,最後離線時,因資料部分未寫入等原因導致檔案系統一致性有問題。
重新組織3及5號盤,修正錯誤,資料100%恢復成功。
此案例中突顯RAID0+1及RAID1+0的安全差別,細細說說吧。
RAID0+1:
結構為,兩塊以上(含兩塊)硬碟先做條帶(RAID0),組成相同的兩組一級邏輯盤。再將兩組邏輯盤做映象(RAID1)。如下圖:
RAID0+1的冗餘性(安全性):只要有一塊盤出錯,它所在的RAID0就會整體離線,只能靠最外層的RAID1的冗餘來支撐。實際上,只能允許一塊盤出錯,這樣如果在4塊以上的硬碟盤陣中,安全性實際會差得多。
利用率:1/2
效率:讀與寫均可以實現N/2(N為硬碟總數)的理論頻寬
實現:容易,控制器無需強勁處理能力,通常也無需大緩衝。
RAID1+0:
結構為,兩塊以上硬碟先做映象(RAID1),組成相同的兩組或兩組以上一級邏輯盤。再將兩組(或兩組以上)邏輯盤做條帶(RAID0)。如下圖:
RAID1+0的冗餘性(安全性):只要有一塊盤出錯,它所在的RAID1中不會有問題,所以每組RAID1中都允許有一塊盤離線。安全性:損壞兩塊盤崩潰的機會只有2/(N-1)。
利用率:1/2
效率:讀與寫均可以實現N/2(N為硬碟總數)的理論頻寬
實現:容易,控制器無需強勁處理能力,通常也無需大緩衝。
上述分析,可以明顯看到,RAID1+0比RAID0+1的安全級別會高很多,其他引數卻相同。所以,需要安全級別高的場合下,一定要選擇RAID1+0。實際上,RAID0+1是華而不實的結構,很少會有它的適用場合。本文提及的案例,如果使用者使用的是RAID1+0,出故障的概率便會低得多了。
本文轉自 張宇 51CTO部落格,原文連結:http://blog.51cto.com/zhangyu/40400,如需轉載請自行聯絡原作者
相關文章
- MySQL資料災難挽救之drop tableMySql
- MySQL資料災難挽救之truncate tableMySql
- MySQL資料災難挽救之Delete\UpdateMySqldelete
- HP-lefthand底層結構詳解及儲存災難資料恢復資料恢復
- 【資料庫資料恢復】ORACLE常見資料災難&資料恢復可能性資料庫資料恢復Oracle
- 伺服器RAID0+1資料恢復伺服器AI資料恢復
- MySQL資料災難挽救之ibdata檔案誤刪恢復MySql
- 基於UNIX系統,邏輯故障的資料災難解讀
- 解決資料災難需要回答的十個問題
- 細數基於ORACLE 資料庫環境的常見資料災難解決方式Oracle資料庫
- oracle資料庫災難挽救應急方案之DML誤操作恢復Oracle資料庫
- Veeam助力TrendMicro解決資料保護和災難恢復挑戰
- oracle資料庫災難挽救應急方案之DDL誤操作恢復(drop)Oracle資料庫
- oracle資料庫災難挽救應急方案之DDL誤操作恢復(truncate)Oracle資料庫
- 【伺服器資料恢復】伺服器RAID0+1資料恢復案例伺服器資料恢復AI
- 五種最讓人“難以預料”的資料洩露方式!
- 研究稱網民難以逃脫谷歌資料大網谷歌
- 資料庫的災備資料庫
- 突破還是災難? 淺談遊戲中的身份轉換與敘事遊戲
- (004)我們一起學Python;閒談資料型別Python資料型別
- 一次奇葩的raid0+1資料恢復經歷AI資料恢復
- 伺服器資料恢復-UNIX類檔案系統資料災難的資料恢復可能性分析伺服器資料恢復
- VMware Live Site Recovery 9.0.1 - 資料中心災難恢復 (DR)
- VMware Live Site Recovery 9.0 - 資料中心災難恢復 (DR)
- VMware Site Recovery Manager 9.0 - 資料中心災難恢復 (DR)
- IT系統災難恢復基本指南
- 談談資料的貨幣化及相關戰略制定
- 一起來談談 Spring AOP!Spring
- 一起來修仙 《以仙之名》不刪檔測試趣味資料曝光
- 資訊資產分級分類及災備要求
- 北京“721災難”風險管控分析
- 99%基金公司難以消除資料孤島?看Smartbi如何助力破僵局
- 談談資料湖和資料倉儲
- 2024年及以後大資料的頂級趨勢大資料
- 雲災備、雲容災、雲備份、資料庫上雲、線下線上雲災備、災備有云等資料庫
- 維數災難:都是孤獨惹的禍
- 機器學習中的維度災難機器學習
- 案發現場:被注入的軟體及 ORA-600 16703 災難的恢復
- 淺談資料庫防火牆技術及應用資料庫防火牆