822
看了這篇文章，再也不用擔心郵件被誤刪除了
一.故障描述
由8塊盤組成的RAID5, 上層是EXT3文件係統,由於誤刪除導致文件係統中的郵件丟失
二.鏡像磁盤
為防止數據恢複過程中由於誤操作對原始磁盤造成二次破壞, 使用winhex軟件為每塊磁盤做鏡像, 以後所有的數據恢複操作都在鏡像盤上進行, 不會對原始磁盤造成影響
鏡像結果如下：
圖一
三.組建RAID
通過分析數據在硬盤中分布的規律， 獲取RAID類型, RAID條帶的大小，以及每塊磁盤的順序。根據分析結果使用UFS組建RAID。
結果如下：
圖二
四.導出目標分區
從組建好的RAID中可以看出,上層劃分了好幾個EXT3分區,通過對每個分區中底層數據的分析, 發現605G的分區裏麵有大量的郵件頭,並且有nsmail目錄, 確認此分區是數據恢複的目標分區,使用UFS軟件將此分區導出,以便後續處理。
圖三
RAID中的所有分區如下：
nsmail文件夾：
圖四
郵件頭示例：
圖五
五.郵件恢複
由於EXT3文件係統中文件刪除後,節點中的文件大小和塊指針都被清零, 因此很難通過常規手段去恢複。針對EXT3文件係統的特點和郵件文件本身的結構，確定算法概要：
在整個文件係統範圍內，做全盤掃描，將找到的郵件文件全部取出，然後根據郵件本身記錄的收件人、發件人、抄送、主題等信息進行整理，最後再將數據遷移到263平台上
詳細過程：
1．完成郵件標識程序，識別收發人、主題等memi標識程序編寫。
2．完成ext3超過48k郵件提取程序編寫。
3．按小於48k、大於48k兩種算法對郵件進行提取。提取同時，生成郵件索引信息庫，並且提取非自由空間和非郵件區。
4．對3中提取的非自由空間和非郵件區進行人工分析，確定有無遺漏的郵件，如果有，確定遺漏的原因，調整算法，重新進行掃描。
5．重複3,4過程，直到最後的非自由空間和非郵件區中沒有遺漏的郵件。
6. 對所有提取出的郵件，按照數據庫中解析到的收件人和發件人歸類，每個賬號一個文件夾，內含收件和發件兩個文件夾。
結果:
第一次 導出郵件 68.2G, 數據量 692,767 個文件
第二次 算法改進後, 導出郵件 77.2G, 數據量 720,209 個文件, 多了3萬文件左右
第三次 再次改進算法, 導出郵件 84.8G, 數據量 895,032 個文件, 比第二次多了174823
總的存儲空間是605G, 郵件區占用84.8G 剩下的有491.6G 自由空間，屬於全零區域，肯定沒有郵件了，非自由空間和非郵件區的垃圾數據有28.6G
經過3次大的算法改進，以及中途無數的細節增刪，至此，剩餘的非自由空間和非郵件區經人工驗證也已經無法找到新的郵件文件，隻剩下一些郵件的中間碎片，無法進行拚接，以及一些雜亂數據，此結果經北亞數據恢複總監親自審核。
示例如下,郵件中間碎片：
圖六
垃圾數據：
圖七
六.驗證數據
驗證數據分為兩部分，一個是郵件數據量的驗證，通過對幾個已知賬號的收件和發件數量的統計，大概估算一下郵件的回複比例。二是郵件正確性的驗證，用FoxMail打開提取出的郵件，查看內容是否正常.幾個賬號的數量如下：
圖八
一些郵件內容：
圖九
圖十
七.移交數據
配合客戶將所有提取出的郵件遷移到263平台
最後更新：2017-06-29 16:31:59