linux下使用extundelete恢復ext3/ext4分區數據

Windows平臺恢復誤刪數據so easy，可是linux就沒那麼簡單了，由於沒有「回收站」。BUT，若是有一天真的不當心誤刪了文件，那如何是好？那就藉助恢復神器extundelete了。

如下均爲本人虛擬機上操做，經測試，文件系統ext3/ext4均適用。

1、安裝extundelete

一、須要安裝依賴包，不然編譯不經過

[root@reed /]#yum install e2fsprogs* -y

二、下載並安裝extundelete

下載地址：https://sourceforge.net/projects/extundelete/files/latest/download

[root@reed /]#tar -jxvf extundelete-0.2.4.tar.bz2 
[root@reed /]#cd extundelete-0.2.4
[root@reed /]#./configure --prefix=/usr/local/extundelete
[root@reed /]#make && make install

三、配置臨時環境變量，若是永久則寫到profile

[root@reed /]#PATH=$PATH:/usr/local/extundelete/bin

四、驗證是否安裝成功

[root@reed /]# extundelete -v
extundelete version 0.2.4
libext2fs version 1.41.12
Processor is little endian.

2、恢復已刪除數據

爲方便測試，新建了一個單獨的分區/dev/sdb1，掛載/reed

[root@reed /]#mount /dev/sdb1 /reed

一、建立測試文件

[root@reed /]# cd /reed/
[root@reed reed]# cp ~/extundelete-0.2.4.tar.bz2 .
[root@reed reed]# echo "reed">>del.file
[root@reed reed]# ll
total 132
-rw-r--r-- 1 root root      5 Mar 16 07:20 del.file
-rw-r--r-- 1 root root 108472 Mar 16 07:20 extundelete-0.2.4.tar.bz2
drwx------ 2 root root  16384 Mar 16 06:45 lost+found

二、刪除文件

[root@reed reed]# rm *
rm: remove regular file `del.file'? y
rm: remove regular file `extundelete-0.2.4.tar.bz2'? y
rm: cannot remove `lost+found': Is a directory
[root@reed reed]# ll
total 16
drwx------ 2 root root 16384 Mar 16 06:45 lost+found

三、查看/reed的inode值

[root@reed reed]# ls -id /reed
2 /reed

四、卸載/reed分區

[root@reed reed]# cd ..
[root@reed /]# umount /reed

五、恢復已刪除數據

注：默認被刪文件會恢復到當前目錄下的RECOVERED_FILES目錄

5.1先查看已刪除文件

[root@reed /]# extundelete /dev/sdb1 --inode=2
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 8 groups loaded.
Group: 0
Contents of inode 2:
0000 | ed 41 00 00 00 10 00 00 ec 98 e8 56 e9 98 e8 56 | .A.........V...V
0010 | e9 98 e8 56 00 00 00 00 00 00 03 00 08 00 00 00 | ...V............
0020 | 00 00 00 00 00 00 00 00 41 02 00 00 00 00 00 00 | ........A.......
0030 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0080 | 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
0090 | 6e 90 e8 56 00 00 00 00 00 00 00 00 00 00 00 00 | n..V............
00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Inode is Allocated
File mode: 16877
Low 16 bits of Owner Uid: 0
Size in bytes: 4096
Access time: 1458084076
Creation time: 1458084073
Modification time: 1458084073
Deletion Time: 0
Low 16 bits of Group Id: 0
Links count: 3
Blocks count: 8
File flags: 0
File version (for NFS): 0
File ACL: 0
Directory ACL: 0
Fragment address: 0
Direct blocks: 577, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Indirect block: 0
Double indirect block: 0
Triple indirect block: 0

File name                                       | Inode number | Deleted status
.                                                 2
..                                                2
lost+found                                        11
extundelete-0.2.4.tar.bz2                         12             Deleted
del.file                                          13             Deleted

標記爲」Deleted」的文件則是被刪除的文件

5.2恢復

[root@reed /]# extundelete --restore-all /dev/sdb1
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 8 groups loaded.
Loading journal descriptors ... 23 descriptors loaded.
Searching for recoverable inodes in directory / ... 
2 recoverable inodes found.
Looking through the directory structure for deleted files ... 
0 recoverable inodes still lost.
[root@reed /]# ll RECOVERED_FILES/
total 112
-rw-r--r-- 1 root root      5 Mar 16 07:25 del.file
-rw-r--r-- 1 root root 108472 Mar 16 07:25 extundelete-0.2.4.tar.bz2

5.3大功告成。

固然還有不少其它參數，如能夠指定恢復某個時間點的文件。

3、延伸知識：linux系統rm刪除文件的原理

轉自：http://blog.csdn.net/grantlee1988/article/details/8057228

不少時候，咱們都會發現，某個進程在對當前文件讀寫，可是咱們依然可以rm， 是否是很奇怪？而windows下面，確定會報錯，」當前文件正在被使用「， 這就得從linux下面刪除文件的原理提及了。
　　
　　
　　 Linux是經過link的數量來控制文件刪除的，只有當一個文件不存在任何link的時候，這個文件纔會被刪除。通常來講，每一個文件都有2個link計數器:i_count 和 i_nlink。
　　
　　 i_count的意義是當前文件使用者（或被調用）的數量,i_nlink 的意義是介質鏈接的數量（硬連接的數量）；能夠理解爲i_count是內存引用計數器，i_nlink是磁盤的引用計數器。
　　
　　當一個文件被某一個進程引用時，對應i_count數就會增長；當建立文件的硬連接的時候，對應i_nlink數就會增長。
　　
　　 對於刪除命令rm而言，實際就是減小磁盤引用計數i_nlink。這裏就會有一個問題，若是一個文件正在被某個進程調用，而用戶卻執行rm操做把文件刪除了，那麼會出現什麼結果呢？當用戶執行rm操做刪除文件後，再執行ls或者其餘文件管理命令，沒法再找到這個文件了，可是調用這個刪除的文件的進程卻在繼續正常執行，依然可以從文件中正確的讀取及寫入內容。這又是爲何呢？
　　
　　這是由於rm操做只是將文件的i_nlink減小了，若是沒其它的連接i_nlink就爲0了；但因爲該文件依然被進程引用，所以，此時文件對應的i_count並不爲0，因此即便執行rm操做，但系統並無真正刪除這個文件，當只有i_nlink及i_count都爲0的時候，這個文件纔會真正被刪除。也就是說，還須要解除該進程的對該文件的調用才行。
　　
　　以上講的i_nlink及i_count是文件刪除的真實條件，可是當文件沒有被調用時，執行了rm操做刪除文件後是否還能夠找回被刪的文件呢？
　　
　　前面說了，rm操做只是將文件的i_nlink減小了，或者說置0了，實際就是將文件名到inode的連接刪除了，此時，並無刪除文件的實體即（block數據塊），此時，若是及時中止機器工做，數據是能夠找回的，若是此時繼續寫入數據，那麼當新數據就可能會被分配到被刪除的數據的block數據塊，此時，文件就會被真正的回收了

 

備註：根據以上原理，實際狀況會出現如下問題，web服務器磁盤空間不夠了，刪除了全部無用日誌仍是先是磁盤空間不足，可是用du -sh /*發現磁盤空間佔用的遠小於硬盤總大小，這就是由於只刪除了一個i_nlink，而還有其餘進程在使用着這些log文件，apache或者tomcat，重啓再看就ok了。