<a href="http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc/index.html">http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc/index.html</a> <a href="http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc2/">http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc2/</a> <a href="http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc3/index.html">http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc3/index.html</a> 要想恢複誤删除的檔案，必須清楚資料在磁盤上究竟是如何存儲的，以及如何定位并恢複資料。本文從資料恢複的角度，着重介紹了 ext2 檔案系統中使用的一些基本概念和重要資料結構，并通過幾個執行個體介紹了如何手工恢複已經删除的檔案。最後針對 ext2 現有實作存在的大檔案無法正常恢複的問題，通過修改核心中的實作，給出了一種解決方案。
對于很多 Linux 的使用者來說，可能有一個問題一直都非常頭疼：對于那些不小心删除的資料來說，怎樣才能恢複出來呢？大家知道，在 Windows 系統上，資源回收筒中儲存了最近使用資料總管時删除的檔案。即便是對于那些在指令行中删除的檔案來說，也有很多工具（例如recover4all，FinalData Recovery）可以把這些已經删除的檔案恢複出來。在Linux 下這一切是否可能呢？
實際上，為了友善使用者的使用，現在 Linux 上流行的桌面管理工具（例如gnome和KDE）中都已經內建了資源回收筒的功能。其基本思想是在桌面管理工具中捕獲對檔案的删除操作，将要删除的檔案移動到使用者根目錄下的 .Trash 檔案夾中，但卻并不真正删除該檔案。當然，像在 Windows 上一樣，如果使用者在删除檔案的同時，按下了 Shift 鍵并确認删除該檔案，那麼這個檔案就不會被移動到 .Trash 檔案夾中，也就無從恢複了。此時，習慣了使用 Windows 上各種恢複工具的人就會頓足捶胸，抱怨 Linux 上工具的缺乏了。但是請稍等一下，難道按照這種方式删除的檔案就真的無從恢複了麼？或者換一個角度來看，使用 rm 指令删除的檔案是否還有辦法能夠恢複出來呢？
<a>背景知識</a>
在開始真正進行實踐之前，讓我們首先來了解一下在 Linux 系統中，檔案是如何進行存儲和定位的，這對于了解如何恢複檔案來說非常重要。我們知道，資料最終以資料塊的形式儲存在磁盤上，而作業系統是通過檔案系統來管理這些資料的。ext2/ext3 是 Linux 上應用最為廣泛的檔案系統，本文将以 ext2 檔案系統為例展開介紹。
我們知道，在作業系統中，檔案系統是采用一種階層化的形式表示的，通常可以表示成一棵倒置的樹。所有的檔案和子目錄都是通過查找其父目錄項來定位的，目錄項中通過比對檔案名可以找到對應的索引節點号（inode），通過查找索引節點表（inode table）就可以找到檔案在磁盤上的位置，整個過程如圖1所示。
<a>圖 1. 檔案資料定位過程</a>
對于 ext2 類型的檔案系統來說，目錄項是使用一個名為 ext2_dir_entry_2 的結構來表示的，該結構定義如下所示：
<a>清單 1. ext2_dir_entry_2 結構定義</a>
在 Unix/Linux 系統中，目錄隻是一種特殊的檔案。目錄和檔案是通過 file_type 域來區分的，該值為 1 則表示是普通檔案，該值為 2 則表示是目錄。
對于每個 ext2 分區來說，其在實體磁盤上的布局如圖 2 所示：
<a>圖 2. ext2 分區的布局</a>
從圖 2 中可以看到，對于 ext2 檔案系統來說，磁盤被劃分成一個個大小相同的資料塊，每個塊的大小可以是1024、2048 或 4096 個位元組。其中，第一個塊稱為引導塊，一般保留做引導扇區使用，是以 ext2 檔案系統一般都是從第二個塊開始的。剩餘的塊被劃分為一個個的塊組，ext2 檔案系統會試圖盡量将相同檔案的資料塊都儲存在同一個塊組中，并且盡量保證檔案在磁盤上的連續性，進而提高檔案讀寫時的性能。
至于一個分區中到底有多少個塊組，這取決于兩個因素：
分區大小。
塊大小。
最終的計算公式如下：
分區中的塊組數＝分區大小/(塊大小*8)
這是由于在每個塊組中使用了一個資料塊位圖來辨別資料塊是否空閑，是以每個塊組中最多可以有（塊大小*8）個塊；該值除上分區大小就是分區中總的塊組數。
每個塊組都包含以下内容：
超級塊。存放檔案系統超級塊的一個拷貝。
組描述符。該塊組的組描述符。
資料塊位圖。辨別相應的資料塊是否空閑。
索引節點位圖。辨別相應的索引節點是否空閑。
索引節點表。存放所有索引節點的資料。
資料塊。該塊組中用來儲存實際資料的資料塊。
在每個塊組中都儲存了超級塊的一個拷貝，預設情況下，隻有第一個塊組中的超級塊結構才會被系統核心使用；其他塊組中的超級塊可以在 e2fsck 之類的程式對磁盤上的檔案系統進行一緻性檢查使用。在 ext2 檔案系統中，超級塊的結構會通過一個名為 ext2_super_block 的結構進行引用。該結構的一些重要域如下所示：
<a>清單 2. ext2_super_block 結構定義</a>
每個塊組都有自己的組描述符，在 ext2 檔案系統中是通過一個名為 ext2_group_desc的結構進行引用的。該結構的定義如下：
<a>清單 3. ext2_group_desc 結構定義</a>
資料塊位圖和索引節點位圖分别占用一個塊的大小，其每一位描述了對應資料塊或索引節點是否空閑，如果該位為0，則表示空閑；如果該位為1，則表示已經使用。
索引節點表存放在一系列連續的資料塊中，每個資料塊中可以包括若幹個索引節點。每個索引節點在 ext2 檔案系統中都通過一個名為 ext2_inode 的結構進行引用，該結構大小固定為 128 個位元組，其中一些重要的域如下所示：
<a>清單 4. ext2_inode 結構定義</a>
第一個索引節點所在的塊号儲存在該塊組描述符的 bg_inode_table 域中。請注意 i_block 域，其中就包含了儲存資料的資料塊的位置。有關如何對資料塊進行尋址，請參看後文“資料塊尋址方式”一節的内容。
需要知道的是，在普通的删除檔案操作中，作業系統并不會逐一清空儲存該檔案的資料塊的内容，而隻會釋放該檔案所占用的索引節點和資料塊，方法是将索引節點位圖和資料塊位圖中的相應辨別位設定為空閑狀态。是以，如果我們可以找到檔案對應的索引節點，由此查到相應的資料塊，就可能從磁盤上将已經删除的檔案恢複出來。
幸運的是，這一切都是可能的！本文将通過幾個實驗來了解一下如何從磁盤上恢複删除的檔案。
<a href="http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc/index.html#main">回頁首</a>
<a>資料塊尋址方式</a>
回想一下，ext2_inode 結構的 i_block 域是一個大小為 EXT2_N_BLOCKS 的數組，其中儲存的就是真正存放檔案資料的資料塊的位置。通常來說，EXT2_N_BLOCKS 大小為 15。在 ext2 檔案系統，采用了直接尋址和間接尋址兩種方式來對資料塊進行尋址，原理如圖3 所示：
<a>圖 3. 資料塊尋址方式</a>
對于 i_block 的前 12 個元素（i_block[0]到i_block[11]）來說，其中存放的就是實際的資料塊号，即對應于檔案的 0 到 11 塊。這種方式稱為直接尋址。
對于第13個元素（i_block[12]）來說，其中存放的是另外一個資料塊的邏輯塊号；這個塊中并不存放真正的資料，而是存放真正儲存資料的資料塊的塊号。即 i_block[12] 指向一個二級數組，其每個元素都是對應資料塊的邏輯塊号。由于每個塊号需要使用 4 個位元組表示，是以這種尋址方式可以通路的對應檔案的塊号範圍為 12 到 (塊大小/4)+11。這種尋址方式稱為間接尋址。
對于第14個元素（i_block[13]）來說，其中存放也是另外一個資料塊的邏輯塊号。與間接尋址方式不同的是，i_block[13] 所指向的是一個資料塊的邏輯塊号的二級數組，而這個二級數組的每個元素又都指向一個三級數組，三級數組的每個元素都是對應資料塊的邏輯塊号。這種尋址方式稱為二次間接尋址，對應檔案塊号的尋址範圍為 (塊大小/4)+12 到 (塊大小/4)2+(塊大小/4)+11。
對于第15個元素（i_block[14]）來說，則利用了三級間接索引，其第四級數組中存放的才是邏輯塊号對應的檔案塊号，其尋址範圍從 (塊大小/4)2+(塊大小/4)+12 到 (塊大小/4)3+ (塊大小/4)2+(塊大小/4)+11。
ext2 檔案系統可以支援1024、2048和4096位元組三種大小的塊，對應的尋址能力如下表所示：
<a>表 1. 各種資料塊對應的檔案尋址範圍</a>
塊大小
直接尋址
間接尋址
二次間接尋址
三次間接尋址
1024
12KB
268KB
64.26MB
16.06GB
2048
24KB
1.02MB
513.02MB
265.5GB
4096
48KB
4.04MB
4GB
~ 4TB
掌握上面介紹的知識之後，我們就可以開始恢複檔案的實驗了。
<a>準備檔案系統</a>
為了防止破壞已有系統，本文将采用一個新的分區進行恢複删除檔案的實驗。
首先讓我們準備好一個新的分區，并在上面建立 ext2 格式的檔案系統。下面的指令可以幫助建立一個 20GB 的分區：
<a>清單 5. 建立磁盤分區</a>
在筆者的機器上，這個分區是 /dev/sdb6。然後建立檔案系統：
<a>清單 6. 在新分區上建立 ext2 檔案系統</a>
并将其挂載到系統上來：
<a>清單 7. 挂載建立的 ext2 檔案系統</a>
在真正使用這個檔案系統之前，讓我們首先使用系統提供的一個指令 dumpe2fs 來熟悉一下這個檔案系統的一些具體參數：
<a>清單 8. 使用 dumpe2fs 熟悉這個檔案系統的參數</a>
應用前面介紹的一些知識，我們可以看到，這個檔案系統中，塊大小（Block size）為4096位元組，是以每個塊組中的塊數應該是4096*8=32768個（Blocks per group），每個塊組的大小是 128MB，整個分區被劃分成20GB/(4KB*32768)=160個。但是為什麼我們隻看到 150 個塊組（0到149）呢？實際上，在 fdisk 中，我們雖然輸入要建立的分區大小為 20GB，但實際上，真正配置設定的空間并不是嚴格的20GB，而是隻有大約 20*109 個位元組，準确地說，應該是 (4885760 * 4096) / (1024*1024*1024) = 18.64GB。這是由于不同程式的計數機關的不同造成的，在使用儲存設備時經常遇到這種問題。是以，這個分區被劃分成 150 個塊組，前 149 個塊組分别包含 32768 個塊（即 128B），最後一個塊組隻包含 3328 個塊。
另外，我們還可以看出，每個索引節點的大小是 128 位元組，每個塊組中包含 16288 個索引節點，在磁盤上使用 509 個塊來存儲（16288*128/4096），在第一個塊組中，索引節點表儲存在 1027 到 1535 塊上。
資料塊和索引節點是否空閑，是分别使用塊位圖和索引節點位圖來辨別的，在第一個塊組中，塊位圖和索引節點位圖分别儲存在 1025 和 1026 塊上。
dumpe2fs 的輸出結果中還包含了其他一些資訊，我們暫時先不用詳細關心這些資訊。
<a>準備測試檔案</a>
現在請将附件中的 createfile.sh 檔案下載下傳到本地，并将其儲存到 /tmp/test 目錄中，這個腳本可以幫助我們建立一個特殊的檔案，其中每行包含 1KB 字元，最開始的14個字元表示行号。之是以采用這種檔案格式，是為了友善地确認所恢複出來的檔案與原始檔案之間的差別。這個腳本的用法如下：
<a>清單 9. createfile.sh 腳本的用法</a>
第 1 個參數表示所生成的檔案大小，機關是 KB；第 2 個參數表示所生成檔案的名字。
下面讓我們建立幾個測試檔案：
<a>清單 10. 準備測試檔案</a>
上面的指令新建立了大小為 35 KB 和 9000KB 的兩個檔案，并為它們各自儲存了一個備份，備份檔案的目的是為了友善使用 diff 之類的工具驗證最終恢複出來的檔案與原始檔案完全一緻。
ls 指令的 –i 選項可以檢視有關儲存檔案使用的索引節點的資訊：
<a>清單11. 檢視檔案的索引節點号</a>
第一列中的數字就是索引節點号。從上面的輸出結果我們可以看出，索引節點号是按照我們建立檔案的順序而逐漸自增的，我們剛才建立的 35K 大小的檔案的索引節點号為 13，10M 大小的檔案的索引節點号為 14。debugfs 中提供了很多工具，可以幫助我們了解進一步的資訊。現在執行下面的指令：
<a>清單12. 檢視索引節點 <13> 的詳細資訊</a>
輸出結果顯示的就是索引節點 13 的詳細資訊，從中我們可以看到諸如檔案大小（35840=35K）、權限（0644）等資訊，尤其需要注意的是最後 3 行的資訊，即該檔案被儲存到磁盤上的 4096 到 4104 總共 9 個資料塊中。
下面再看一下索引節點 14 （即 testfile.10M 檔案）的詳細資訊：
<a>清單13. 檢視索引節點 <14> 的詳細資訊</a>
和索引節點 13 相比，二者之間最重要的差別在于 BLOCKS 的資料，testfile.10M 在磁盤上總共占用了 2564 個資料塊，由于需要采用二級間接尋址模式進行通路，是以使用了4個塊來存放間接尋址的資訊，分别是24588、25613、25614和26639，其中25613塊中存放的是二級間接尋址的資訊。
<a>恢複删除檔案</a>
現在将剛才建立的兩個檔案删除：
<a>清單14. 删除測試檔案</a>
debugfs 的 lsdel 指令可以檢視檔案系統中删除的索引節點的資訊：
<a>清單15. 使用 lsdel 指令搜尋已删除的檔案</a>
回想一下 inode 結構中有 4 個有關時間的域，分别是 i_atime、i_ctime、i_mtime和i_dtime，分别表示該索引節點的最近通路時間、建立時間、修改時間和删除時間。其中 i_dtime域隻有在該索引節點對應的檔案或目錄被删除時才會被設定。dubugfs 的 lsdel 指令會去掃描磁盤上索引節點表中的所有索引節點，其中 i_dtime 不為空的項就被認為是已經删除的檔案所對應的索引節點。
從上面的結果可以看到，剛才删除的兩個檔案都已經找到了，我們可以通過檔案大小區分這兩個檔案，二者一個大小為35K，另外一個大小為10M，正式我們剛才删除的兩個檔案。debugfs 的 dump 指令可以幫助恢複檔案：
<a>清單16. 使用 dump 指令恢複已删除的檔案</a>
執行上面的指令之後，在 /tmp/recover 目錄中會生成兩個檔案，比較這兩個檔案與我們前面備份的檔案的内容就會發現，testfile.35K.dump 與 testfile.35K.orig 的内容完全相同，而 testfile.10M.dump 檔案中則僅有前 48K 資料是對的，後面的資料全部為 0 了。這是否意味着删除檔案時間已經把資料也同時删除了呢？實際上不是，我們還是有辦法把資料全部恢複出來的。記得我們剛才使用 debugfs 的 stat 指令檢視索引節點 14 時的 BLOCKS 的資料嗎？這些資料記錄了整個檔案在磁盤上存儲的位置，有了這些資料就可以把整個檔案恢複出來了，請執行下面的指令：
<a>清單 17. 使用 dd 指令手工恢複已删除的檔案</a>
比較一下最終的 testfile.10M.dd 檔案和已經備份過的 testfile.10M.orig 檔案就會發現，二者完全相同：
<a>清單 18. 使用 diff 指令對恢複檔案和原檔案進行比較</a>
資料明明存在，但是剛才我們為什麼沒法使用 debugfs 的 dump 指令将資料恢複出來呢？現在使用 debugfs 的 stat 指令再次檢視一下索引節點 14 的資訊：
<a>清單 19. 再次檢視索引節點 <14> 的詳細資訊</a>
與前面的結果比較一下不難發現，BLOCKS後面的資料說明總塊數為 14，而且也沒有整個檔案所占據的資料塊的詳細說明了。既然檔案的資料全部都沒有發生變化，那麼間接尋址所使用的那些索引資料塊會不會有問題呢？現在我們來檢視一下 24588 這個間接索引塊中的内容：
<a>清單 20. 檢視間接索引塊 24588 中的内容</a>
顯然，這個資料塊的内容被全部清零了。debugfs 的dump 指令按照原來的尋址方式試圖恢複檔案時，所通路到的實際上都是第0 個資料塊（引導塊）中的内容。這個分區不是可引導分區，是以這個資料塊中沒有寫入任何資料，是以 dump 恢複出來的資料隻有前48K是正确的，其後所有的資料全部為0。
實際上，ext2 是一種非常優秀的檔案系統，在磁盤空間足夠的情況下，它總是試圖将資料寫入到磁盤上的連續資料塊中，是以我們可以假定資料是連續存放的，跳過間接索引所占據的 24588、25613、25614和26639，将從24576 開始的其餘 2500 個資料塊讀出，就能将整個檔案完整地恢複出來。但是在磁盤空間有限的情況下，這種假設并不成立，如果系統中磁盤碎片較多，或者同一個塊組中已經沒有足夠大的空間來儲存整個檔案，那麼檔案勢必會被儲存到一些不連續的資料塊中，此時上面的方法就無法正常工作了。
反之，如果在删除檔案的時候能夠将間接尋址使用的索引資料塊中的資訊儲存下來，那麼不管檔案在磁盤上是否連續，就都可以将檔案完整地恢複出來了，但是這樣就需要修改 ext2 檔案系統的實作了。在 ext2 的實作中，與之有關的有兩個函數：ext2_free_data 和 ext2_free_branches（都在 fs/ext2/inode.c 中）。2.6 版本核心中這兩個函數的實作如下：
<a>清單 21. 核心中 ext2_free_data 和 ext2_free_branches 函數的實作</a>
注意第 832 和 875 這兩行就是用來将對應的索引項置為 0 的。将這兩行代碼注釋掉（對于最新版本的核心 2.6.23 可以下載下傳本文給的更新檔）并重新編譯 ext2 子產品，然後重新加載新編譯出來的子產品，并重複上面的實驗，就會發現利用 debugfs 的 dump 指令又可以完美地恢複出整個檔案來了。
顯然，這個更新檔并不完善，因為這個更新檔中的處理隻是保留了索引資料塊中的索引節點資料，但是還沒有考慮資料塊位圖的處理，如果對應的資料塊沒有設定為正在使用的狀态，并且剛好這些資料塊被重用了，其中的索引節點資料就有可能會被覆寫掉了，這樣就徹底沒有辦法再恢複檔案了。感興趣的讀者可以沿用這個思路自行開發一個比較完善的更新檔。
<a>小結</a>
本文介紹了 ext2 檔案系統中的一些基本概念和重要資料結構，并通過幾個執行個體介紹如何恢複已經删除的檔案，最後通過修改核心中 ext2 檔案系統的實作，解決了大檔案無法正常恢複的問題。本系列的下一篇文章中，将介紹如何恢複 ext2 檔案系統中的一些特殊檔案，以及如何恢複整個目錄等方面的問題。
<a>下載下傳</a>
描述
名字
大小
下載下傳方法
建立測試檔案使用的腳本
createfile.sh
2KB
<a href="http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc/createfile.sh">HTTP</a>
針對 2.6.23 版本核心解決大檔案無法恢複問題的更新檔
indirect_index.patch
<a href="http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc/indirect_index.patch">HTTP</a>
<a href="http://www.ibm.com/developerworks/cn/whichmethod.html">關于下載下傳方法的資訊</a>
<a>參考資料</a>
<a href="http://tldp.org/HOWTO/Ext2fs-Undeletion.html">Linux Ext2fs Undeletion mini-HOWTO</a>
<a href="http://www.oreilly.com/catalog/understandlk/">Understanding the Linux Kernel</a>
<a href="http://www.kernel.org/pub/">Linux kernel source code</a>