【linux】--- 恢复删除的文件

关注

转载最新推荐文章于 2026-05-17 09:01:22 发布 293 阅读 AI 写同款· GEO 优化 ›

先介绍下一些文件的基本概念：

· 文件实际上是一个指向inode的链接, inode链接包含了文件的所有属性, 比如权限和所有者, 数据块地址(文件存储在磁盘的这些数据块中). 当你删除(rm)一个文件, 实际删除了指向inode的链接, 并没有删除inode的内容. 进程可能还在使用. 只有当inode的所有链接完全移去, 然后这些数据块将可以写入新的数据.

· proc文件系统可以协助我们恢复数据. 每一个系统上的进程在/proc都有一个目录和自己的名字，里面包含了一个fd(文件描述符)子目录(进程需要打开文件的所有链接). 如果从文件系统中删除一个文件, 此处还有一个inode的引用:

1.第一种方法 lsof

当进程打开了某个文件时，只要该进程保持打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。

在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。

大多数与 lsof 相关的信息都存储于以进程的 PID 命名的目录中，即 /proc/1234 中包含的是 PID 为 1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。

lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。

进程在运行中，接下来我就把/var/log/messages这个文件删掉

shell> rm /var/log/messages

删掉之后，我再来看看这个进程的变化

shell> lsof |grep /var/log/messages

rsyslogd 1737 root 1w REG 8,2 5716123 652638 /var/log/messages (deleted)

大家看到有变化了吧，对比两个之后发现多了(deleted)。要找到这个文件在哪还要看看这个

PID:1737 FD:1 那我们有直接进入/proc/1737/FD/1用ll查看一下

shell> cd /proc/1737/fd/

shell> ll

total 0

lrwx------ 1 root root 64 Dec 23 13:00 0 -> socket:[11442]

l-wx------ 1 root root 64 Dec 23 13:00 1 -> /var/log/messages (deleted)

l-wx------ 1 root root 64 Dec 23 13:00 2 -> /var/log/secure

lr-x------ 1 root root 64 Dec 23 13:00 3 -> /proc/kmsg

l-wx------ 1 root root 64 Dec 23 13:00 4 -> /var/log/maillog

看到了1对应/var/log/messages (deleted），看看文件是不是我们要的文件:

shell> head -5 1

Nov 14 03:11:11 localhost kernel: imklog 5.8.10, log source = /proc/kmsg started.

Nov 14 03:11:11 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="1241" x-info="http://www.rsyslog.com"] start

Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpuset

Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpu

Nov 14 03:11:11 localhost kernel: Linux version 2.6.32-431.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

对比备份文件：

shell> head -5 /var/log/message_bac

Nov 14 03:11:11 localhost kernel: imklog 5.8.10, log source = /proc/kmsg started.

Nov 14 03:11:11 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="1241" x-info="http://www.rsyslog.com"] start

Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpuset

Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpu

Nov 14 03:11:11 localhost kernel: Linux version 2.6.32-431.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

对比发现数据是一样的，恢复

shell> cat 1 > /var/log/messages

对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用。

2.第二种方法 extundelete

测试误操作删除以下文件

/usr/local/dbdata/gperftools-2.4.tar.gz #文件

/usr/local/dbdata/pcre-8.32 #目录
执行误操作：

# rm -rf /usr/local/dbdata/gperftools-2.4.tar.gz /usr/local/dbdata/pcre-8.32
将误操作所在分区进行只读保护

如果确定文件被误删，在没有备份的情况下请马上对分区实施写入保护（预防新的写入覆盖误删的块数据，因此权限给只读）：

# #
数据恢复工具安装

工具安装部署

官方网站是http://extundelete.sourceforge.net/ ，其目前的稳定版本是extundelete-0.2.4.

工具下载

# wget https://nchc.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.bz2
解压安装

依赖包

# yum -y install gcc-c++ e2fsprogs.x86_64 e2fsprogs-devel.x86_64
# tar -jxvf extundelete-0.2.4.tar.bz2
# cd extundelete-0.2.4
# ./configure
# make && make install
验证安装结果

# extundelete -v
文件恢复过程

恢复指定文件：

原理：从根节点(inode=2)开始找到被删除文件的i节点，然后recover i节点。

以下是模拟删除gperftools-2.4.tar.gz（文件）和pcre-8.32 （目录）

先检测被删除的文件有哪些：

# extundelete /dev/sdb --inode 2

可以看到，有以下两个

gperftools-2.4.tar.gz 15 Deleted

pcre-8.32 655361 Deleted
注意：恢复过程不要在误删分区进行，谨防inode. block块相互覆盖

先恢复文件（可根据文件名进行恢复）：

# extundelete /dev/sdb --restore-file gperftools-2.4.tar.gz

恢复目录（根据目：# extundelete /dev/sdb --restore-directory pcre-8.32

最后会在当前目录下看到一个名为RECOVERED_FILES的目录，在目录里就可以看到被误删除的文件以及目录：