資料恢複故障描述：
原存儲為12塊2T硬碟組成的Linux RAID6，檔案系統均為EXT3，此存儲上劃有3個LUN，每個均為6TB大小，某天在RAID失效後，維護人員為了搶救資料，對此失效的存儲重進行配置設定RAID，并進行了初始化。
初始化進行很長時間後，維護人員察覺到情況有異，便強制停止初始化，但初始化已達到 50%以上。資料部分已被不可逆的破壞。
資料恢複故障分析：
故障的起因僅僅是RAID失效，維護人員随後的搶救資料過程中用11塊硬碟進行重配置設定RAID5，并進行長時間的初始化，這對原始資料是不可逆的損壞，後經證明，僅第三個LUN可用普通RAID6方法恢複出資料，但第三個LUN并沒有客戶想要的要的重要資料，重要的資料主要集中在第一個LUN。
由于此案例的故障極其複雜，我公司接到客戶送修時已經在國内資料恢複公司之間轉手多次，包括多家知名資料恢複公司，仍未解決。
資料恢複過程：
恢複過程分成4步：
1．分析原始12塊磁盤RAID6的RAID和磁盤的組織結構。
2．分析重配置設定RAID5時RAID和磁盤的組織結構。
3．判斷可恢複性，以及怎麼實作恢複程式的算法。
4. 恢複及修複。
快速分析出原始RAID6的結構，但因為底層RAID6和RAID5大量的資訊重合導緻分析重配置設定RAID5的結構時比較困難，整整花費了 1天時間。
第一步和第二步已完成，經分析，被初始化破壞的資料可用其它方法進行還原，制定出恢複算法，花費一天寫程式及進行程式算法的校正，程式把12塊磁盤中原始資料的第一和第二個LUN分别鏡像到搭好的兩個7TB 的存儲上。
經驗證第二個LUN資料完全正常，但最重要的第一個LUN前有大約有10MB資料的破壞，這前 10MB資料很要命，EXT3的根目錄和第一個塊組的I節點全在這前10MB裡面，然後使用資料恢複常用的軟體UFS Explorer 和 R-Studio 的恢複效果都相當不理想 ，可能是存儲較大的原因。
在這種情況下隻得自行修複損壞的EXT3檔案系統，自行寫一個程式進行EXT3孤目錄查找，找到了根目錄下有3個了目錄，重建根目錄和I節點，用 檔案系統解析程式打開已完全正常，但為了保證原始資料的一些權限和屬性，在LINUX簡單修複，LINUX已能正常挂載，然後在LINUX把檔案用 cp 指令進行拷貝格式化好的EXT3 的單塊磁盤的分區上。這樣客戶使用資料時，不再需要别的任何設定，直接 cp 後，檔案目錄結構和屬性都和原來一模一樣。
圖一：
<a href="https://s3.51cto.com/wyfs02/M00/8F/16/wKioL1jTbz2hs7O4AAIS4bF-Cr8984.jpg-wh_500x0-wm_3-wmp_4-s_2741195988.jpg" target="_blank"></a>
圖二：
<a href="https://s2.51cto.com/wyfs02/M01/8F/18/wKiom1jTb1bhjc8IAAIfDv1WzJg611.jpg-wh_500x0-wm_3-wmp_4-s_3400958100.jpg" target="_blank"></a>
圖三：
<a href="https://s5.51cto.com/wyfs02/M01/8F/16/wKioL1jTb2aSl317AAJaWdOvLlY958.jpg-wh_500x0-wm_3-wmp_4-s_3967295175.jpg" target="_blank"></a>
資料恢複結論：
用時3天，資料100%恢複成功。
本文轉自 宋國建 51CTO部落格，原文連結：http://blog.51cto.com/sun510/1909633，如需轉載請自行聯系原作者
![筆試面試題目：滑動視窗(二)[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)