今天剛剛完成在 ext3 file system 裡拯救被 rm -r blah* 刪掉的資料的任務。學會了 undelete 新招術。

事情是昨天發生的，我作了一些 googling 之後，發現有

1. e2undel 和
2. recover

可以給 ext2 fs 用。不幸的是也只能給 ext2 fs 用，沒辦法用在 ext3 fs 上。

Why not? debian-user mailing list 上有人 這樣子說明 ，我來講的話就是 ext3 在 unlink 檔案的時候會把 inode 裡與檔案相關的資訊一起 zero 掉 (ext2 不會)。所以資料雖然還在，但描述檔案位置的資訊已經不見了，那些工具即無法從 inode 裡找出任何可以用來 undelete 的東西。

不過，inode 這條路走不通，還是有方法。 那篇文章 也提到在 ext3 上唯一能進行 undelete 的方法，就是對整個磁碟/分割區作掃瞄。

為了方便我們掃瞄磁碟/分割區裡的 block，要祭出 sleuthkit 來。我花了一點時間研究這組工具之後，似乎看不到有自動掃瞄的功能，這表示得要自己寫程式來搞。

不用講太多，直接參考程式 (Python):

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

from popen2 import popen3
from time import strftime

if __name__ == '__main__':
  bcnt_start = 00020123 # block 搜尋起點
  bcnt_stop  = 00223433 # block 搜尋終點

  # 欲搜尋的字串
  keyword = "be searched word"
  # 紀錄檔名稱
  logfn = "result.%s.log" % strftime("%Y%m%d-%H%M%S")

  i = bcnt_start
  while i <= bcnt_stop:
    # 每掃瞄到一個 block 開關一次檔
    # 用意是 flush write buffer (對，這種寫法很醜)
    logfile = open( logfn, 'a+' )
    # 顯示進度而已，沒別的用處
    q, r = divmod(i, 100)
    if r == 0:
      msg = "processed to block %d / %d (%%%f)" % \
            ( i, bcnt_stop, float(i-bcnt_start)/(bcnt_stop-bcnt_start)*100 )
      print msg
      logfile.write( msg+"\n" )

    # 用 sleuthkit 裡的 dcat 工具程式把區塊資料抓出來
    # 照理說不應用直接用 block device /dev/hdb1 的
    # 不過我沒有多餘又夠大的磁碟來放 dd image
    # 這種作法不好，能免則免
    stdout, stdin, stderr = \
        popen3( "dcat -f linux-ext3 -v /dev/hdb1 %d" % i )
    str = stdout.read()

    # 對 block 內容作搜尋
    if str.find( keyword ) != -1:
      msg = "block %d has %s" % ( i, keyword )
      print msg
      logfile.write( msg+"\n" )

    logfile.close()
    i+=1

這個程式只能找出小於 block size，又具有相同字串內容的檔案資料 (當然是因為我要救的就是這種檔案)。可以算是加強版的 grep 吧，不過要改成搜尋二進位資料也很容易就是了。

程式的執行效率不太好，畢竟是只用了三十分鐘趕出來的 (而且我又不太會寫程式)，用來搜尋 20G 左右的資料大概要花兩天以上的時間 (on P4 2.0G w/512MB+ ram)。僅僅是能用而已。

如果需要在 ext3 裡面救比較複雜/大的檔案，就得仔細研究一下 ext3 的細節，而且多花點時間寫個真正的工具出來了。

最後提一下，要能在 ext2/ext3 裡把 rm 掉的檔案救回來，有幾個關鍵：

1. 儘快 umount；磁碟掛在系統裡愈久，資料被覆寫掉的機會就愈大，一旦被覆寫掉，要救回來就不是那麼簡單的事了。

   如果 rm 錯檔案的慘劇發生在 SGI 的 XFS 上，根據 google 到的資料 顯示，應該會比 ext3 更難 undelete。

2. 愈了解檔案的內容或格式，救回檔案的機會愈大。從這次的經驗來看，如果完全不知道想要拯救的檔案內容，那在 ext3 上大概就沒辦法把資料抓出來了。這個最後的大絕招「磁碟掃瞄法」，完全依靠對資料內容的掌握而論成敗。

希望大家的資料都健健康康的，頭腦不清楚的時候千萬不要下 rm 喔！大家也要幫我禱告 >_< 這種事是會發生在任何人身上的 :~~~~