ext3文件系统恢复被删文件

大家都知道，在linux系统中是没有回收站的概念的，一旦rm命令删除某个文件之后，就找不回来。不过其实这时还是有救的，之前大概清楚个概念，知道有救，但如何救就没怎么详细去了解了。那么这次我们来实际操作下。

其实为什么说还有救呢？说这个之前需要对ext3文件系统有个大概的了解。 在ext3文件系统中我们创建一个文件时，它首先会在ext3文件系统的inode表申请个inode号，然后再将文件的信息以及数据写入。那么inode号又是什么呢？ inode号里面包括两部分，一个是metadata，即是元数据，简单理解就是这个文件的文件名，大小，权限，访问时间等等，也就是除了这个文件的内容数据之外的信息。 如图，创建了一个新文件“testfile”，我们可以用stat命令来查看它的信息；

另一个是一个 pointer 指针。该指针指向真正的数据存放的block数据区。所以通常在我们查看一个文件内容时，我们通过文件名找到对应的inode号，然后再通过这个inode号里面的指针，再找到真正的数据。

而一个文件对应一个inode号，无论文件小到1，2K还是大到1，2GB都一样。在我们创建文件系统时，就会自动创建inode表，我们的inode号也就属于，来自于这个inode表。当然默认的inode表也是有大小的。达到了默认的上限值后，我们就无法创建文件咯。 我们可以通过“df -i”这个命令去查看，每个文件系统的inode的使用情况。通常按照默认的划分都够用了。当然如果你的服务器专门处理些小邮件，小文件的，你可以适当调整inode表的大小，让它更大一些。 如图，我们可以看到各文件系统的inode的总数量，以及使用了多少，剩余多少，以及占用的百分比；

那么当我们执行命令，“rm -f testfile” 时，这时其实删除的只是对应这个文件的文件名与其inode的关联，数据其实还在，同时这个文件之前所占用的inode号被标记为可用状态，所以这个使用就不要再创建新的文件了，也就是对这个文件系统不要做任何动作，我想这个大家也都清楚。因为如果再创建新的文件，在ext3文件系统中，新的文件会复用之前被标记为可用状态的inode号，而这时你的数据也就岌岌可危了。

如上图，test文件inode号为98315，而删除之后，再建立个新的文件，它的inode号使用了之前空余出的相同的inode号。当然这个在不同文件系统是不同的，例如在redhat的GFS文件系统中，被删的文件的inode号是会保留下来的，新的文件会用新的inode号。当然在GFS中也可以通过命令的形式去清空无效被删的inode号，将其还原成可被用的状态。

那么我们现在知道数据还是存在的，那么接着我们如何来恢复呢？ 首先我们需要一个恢复数据的工具，所谓工欲善其事，必先利其器； 我们先来下载，编译下这个ext3grep软件吧，当然前提要安装好gcc噢！

wget http://ext3grep.googlecode.com/files/ext3grep-0.10.1.tar.gz
tar -zxvf ext3grep-0.10.1.tar.gz
cd ext3grep-0.10.1
./configure
make
make install 

安装好后，我们就先在准备下环境，单独挂载个文件系统，在删除个文件。这时我们看到之前文件的inode号为8052。在处理前，我们需要先卸载该文件系统。

但若因某进程，持续访问该文件系统，无法卸载，可通过以下方式 kill掉正在使用这个目录的进程：

fuser -k /test

当然，这样做如果你不好确保是否安全的话，可以先运行lsof这个命令，来查看所以连接到这个目录的进程： 

lsof +D /test 

确认好了然后再kill掉。

我们首先执行：

ext3grep /dev/sdb1 --ls --inode 2

/dev/sdb1  是我之前卸载的ext3文件系统。

–inode 2  的意思是指定从/dev/sdb1的文件系统的root根来寻找。

这时我们从上图黄色标识的地方找到了web目录的inode号，然后我们接着对web目录的inode号来搜索，当然这里还显示了一个之前删除的文件web.txt。

如上图，我们可以看到webfile和它的inode号，8052。 然后指定相关路径，以及被删的文件。

当我们看到 Restoring web/webfile时，说明已经成功恢复了。 接着在执行命令的当前目录下找到RESTORED_FILES目录下的对应目录的被删文件，然后我们可以看到被删文件的内容和之前一样。 然后我们再将之前的/dev/sdb1挂载起来。

这时我们可以看到在该目录的文件已经被恢复成功了。