恢复rm删除的文件--危险的rm(转自 power的博客 )

 

转自 power的博客

对于rm,很多人都有惨痛的教训。我也遇到一次，一下午写的程序就被rm掉了，幸好只是一个文件，第二天很快又重新写了一遍。但是很多人可能就不像我这么幸运了。本文收集了一些恢复rm删除的文件的方法，给大家作为参考。

    首先，最好的方法是避免这个问题，以下是几点建议:

    1、rm -rf误操作的后果是可怕的，rm -f也要三思而行，不能轻易使用。
　　2、做好数据备份。
　　3、用一些策略避免出错:
       提倡在shell下用 TAB 补全，用脚本执行任务，减少出错的机会。
       或者编写一个脚本，起名rm，在脚本里将真实的rm改为mv ，将删除的都mv到一个指定的目录里面，定期清理。

　　那么rm删除的文件还能恢复吗?

    rm的man里面有如下说法:
　　请注意，如果使用 rm 来删除文件，通常仍可以将该文件恢复原状。如果想保证该文件的内容无法还原，请考虑使用 shred。

　　所以理论上rm删除的文件是还能恢复的。删掉文件其实只是将指向数据块的索引点(information nodes)释放，只要不被覆盖，数据其实还在硬盘上，关键在于找出索引点，然后将其所指数据块内的数据抓出，再保存到另外的分区。在用rm误删除文件后，我们要做的第一件事就是保证不再向误删文件的分区写数据。

    通常我们可以有以下几种选择：

    1、借助工具。
　　2、自己写程序。你需要会编程并了解对应的文件系统。
　　3、如果数据很有用，也许可以找专业公司抢救。

   工具

   1、The Sleuth Kit　http://www.sleuthkit.org/sleuthkit/(Autopsy是它的一个图形前端)
   2、Foremost　　　　http://foremost.sourceforge.net
　 3、一个全能的工具，Finaldata,可以恢复unix/linux/dos下误删的文件。对于unix，支持这些产品，   　　　　Solaris、AIX和HP-UX。对于linux，支持EXT2的文件系统。对于dos，支持FAT 12/16/32, NTFS 4/5/5.1 的文件系统。

   4、如果文件系统是ext2(对ext3无效):
    　ext3的删除机制是直接把 inode data 删除了，所以造成 ext3 无法反删除(ext3设计为无法恢复被删除的文件)。
          unrm
          ext2ed
　　　　　debugfs(undel lsdel )
          recover
          Midnight Commander(mc)
          e2undel
          tct
　　5、如果文件系统是FAT32或者NTFS:
　　　　　EasyRecovery
　　　　　Finaldata

    6、freebsd如果使用了rm，可以试一下undelete这个命令.

　　7、有人用debugfs恢复ext3被rm的资料
　　　 http://www.sosdb.com/jdul/dispbbs.asp?boardID=6&ID=342&page=1

　　8、当进程打开了某个文件时，只要该进程保持打开该文件，lsof可以用来恢复删除文件。

　　编程的方式

    1、CU上有人写了一个小程序恢复Solaris上误删的数据
       http://bbs.chinaunix.net/viewthread.php?tid=16642
    2、恢复ext3被rm的资料
　　　 http://blog.seety.org/everydaywork/2005/3/11/248/

今天剛剛完成在 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 喔！大家也要幫我禱告 >_< 這種事是會發生在任何人身上的 :~~~~

　　3、如何恢复 Linux 上删除的文件，第 2 部分
　　　 http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc2/?S_TACT=105AGX52