如何恢复rm -rf删除的数据

芝华塔尼欧917

于 2024-04-28 10:35:02 发布

阅读量1.2k

点赞数 24

文章标签： linux

本文链接：https://blog.csdn.net/sll917/article/details/138270335

版权

index

一、删除数据的两种场景

第 1 个是在执行 rm -rf 删除文件时，该文件正在被进程使用
第 2 个是这个文件并没有被其他进程所使用，而被误删除

二、为什么数据可以恢复

神奇的link计数器
在这里插入图片描述

既然我执行了 rm -rf 命令，不就是删除文件了吗，为什么又可以恢复数据呢？首先我来为你介绍一下其原由，对于第 1 种进程正在使用文件的场景，数据可以恢复是由因为 Linux 里，每个文件都有 2 个 link 计数器：i_count 和 i_nlink。

i_count 的作用是当一个文件被一个进程引用时，它的数值会加 1，也就是说它记录的是文件被进程引用的次数。i_nlink 的作用则是记录文件产生硬链接的个数。Linux 系统只有在两个数值都清零的时候，文件才被系统认为是删除的。如果我们执行了 rm -rf，却并没有把 i_count 删除，假设此时删除文件有进程在使用，那么它（i_count）数值不为 0。这个时候就是文件看似被删除，但在操作系统还是能便捷的恢复回来。

这就是第 1 种场景删除数据能够被找回的原因（由于 i_count 不为 0）。 在这里插入图片描述

第 2 种场景是将没有被进程使用的文件误删除，此时i_count 和 i_nlink 都为 0。这个时候文件的 inode 连接信息已经被删除了，我们就需要通存放文件的 block 单元，做数据块的数据找回。在系统上我们能看到的文件内容包括：文件名、文件大小、内容，但实际上它的存储依赖两个非常重要的单元，一个是 inode，它用于存放文件的相关元数据，它的元数据里会有一个类似于索引的值，能够索引到后面具体存放数据的 block 单元， block 是一个数据块，用来实际存放数据。我们在删除文件时，其实是把 inode 的链接删除了，但是 block 数据块，并没有删除。

所以这个时候我们依然可以通过分析后端的 block 块，对文件进行恢复。因为 block 块保存着真实的数据，理论上可以作完整的找回数据，不过有一个风险：如果有进程在不断往磁盘写数据时，需要申请新的 block 块，如果操作系统分配已删除文件的 block 块时，那么新的写入数据就会覆盖 block 原来的数据，这时就会造成数据真正丢失的风险。

所以，如果出现这样场景造成数据误删除，需要第一时间 umount 目录所在的磁盘设备。如果没有其他进程在不断地往同一个磁盘块（block）里写数据，那么你的数据理论上还是在 block 块里面，依然可以通过相关分析把数据找回。

这就是我们为什么可以在这两个场景中把数据找回的原因，那么接下来我将讲解如何来恢复数据。我会通过两个案例来进行演示。

三、案例演示

我们先演示第 1 种场景，第 1 种场景是文件在被进程使用过程中被删除，这种场景该如何去恢复文件呢？

3.1、恢复在被进程使用过程中被删除的文件

新建文件delete.txt，文件内容为delete-test
我们用tail这个命令一直占用这个文件
接下来在另一个窗口，我同样到/test 目录下，而此时我要执行的是 rm -rf ./deletefile.txt，这样就“彻底”把这个文件删除。接下来我们通过 ls，可以看到本地已经没有这个文件了。
现在我们已经模拟出文件在进程使用过程中被删除的场景，那么接下来我们来演示恢复该文件。
首先需要找到是哪个进程在使用这个文件，我们可以通过 lsof 命令，grep 刚刚删除的文件名称（deltefile.txt），会列出当前使用文件的进程。我们会看到tail 命令正在使用，它（进程）的 pid 是 3609。
接下来我们要根据这条线索去恢复数据。我们知道该进程会有使用的文件句柄，那么我们对该进程的文件句柄目录进行查找，cd 到 /proc/{pid}/fd 目录下（这里 pid 为3609），我们到这个目录下，输入 ls -l 命令，这个时候我们会看到，使用这个文件（/root/delete/deletefile.txt）并且它的文件句柄为 3。
接下来我们要想办法把这个文件进行恢复，输入cp 3 /opt/recovertest/deletefile.txt_bak，这时我就把这 3 个文件做了一个拷贝，实现将数据恢复到 /opt/recovertest/deletefile.txt_bak 文件。
这个时候cd /opt/recovertest/，cat deletefile.txt_bak 看一下里面的内容，可以发现这个文件的内容与刚刚生成的的测试文件内容一致，所以刚刚删除的文件恢复完毕。

接下来我来演示误删数据场景2（在没有进程使用文件的情况下，如何恢复误删的文件）。演示这种场景，保险起见我在本地多挂载了一块 SDB 的独立硬盘设备。

3.2、恢复没有被进程使用过程中删除的文件

安装 extundelete

<span style="background-color:#282c34"><span style="color:#abb2bf">wget https://ncu.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.bz2
tar -jxvf extundelete-0.2.4.tar.bz2
<span style="color:#e6c07b">cd</span> extundelete
<span style="color:#e6c07b">chmod</span> +x ./configure
yum install -y e2fsprogs-devel e2fsprogs e2fsprogs-libs gcc-c++ gcc  <span style="color:#5c6370"><em>##安装环境依赖</em></span>
./configure
make && make install
</span></span>

这种情况要如何恢复数据呢？我们需要安装 extundelete 这个工具。登录到我的测试机上，在这个演示场景里，挂载一块独立硬盘设备 /dev/sdb 并作数据格式化。完成格式化后。把单独的 sdb 设备，挂载到 test 目录下（mount /dev/sdb /test），接下来在 test 目录下生成一个内容为“deletetest ”的测试文件file(echo ‘deletetest’>file),这个时候本地目录会生成一个测试的文件：file，再新建一个叫 testdir 的目录（mkdir /test/testdir），那么这时本地既有文件又有目录，也就是我接下来要演示删除的这些文件。

我们可以通过 rm -rf ./*，直接把当前目录下的文件整体删除。然后我需要恢复这个文件，原理就是：通过分析它的 block 块，来恢复 inode 链接，要分析并恢复已删除文件的链接，我们要用到一些工具，这里推荐你使用一个叫 extundelete 的命令，它是在 Linux 下基于 ext3\ext4 的文件分析工具，可以对文件系统已删除的文件进行分析，并进行数据恢复。在这里插入图片描述