debugfs恢复Ext3的文件系统中被rm、rm -f 掉的文件 分类: ...

ls -d #  -d或--directory   显示目录名称而非其内容。

ls -i #    -i或--inode   显示文件和目录的inode编号

如何在Ext3的文件系统中恢复被rm掉的文件。

[root@Gw za]# debugfs
debugfs 1.39 (29-May-2006)
debugfs: open /dev/sda3  #先使用df命令得到删除文件所在的设备,如下图:


debugfs: ls -d #  -d或--directory   显示目录名称而非其内容。
1556130 (12) .    1166977 (12) ..    1556131  
1556139 (20) abc  
1556134 (16) za.sh    1556133
1556140 (3756) zabbixStatistic.sh.bak   <1556144> (3724) hoho  
<1556144> (3712) 00  
debugfs: close
debugfs: quit

[root@Gw za]#

假设我们有一个文件名叫 ‘test.txt’

$ls -il test.txt
15 -rw-rw-r– 2 root root 20 Apr 17 12:08 test.txt

注意:: “-il” 选项表示显示文件的i-node号(15),如果你不知道Unix/Linux文件系统的“I结点”的话,你有必要先补充一下相关的知识。简单说来,i结点就是操作管理文件的一个标识号。

我们再看一下其内容:

$ cat test.txt
this is test file

好,现在我们开始删除文件:.

$rm test.txt
rm: remove write-protected regular file `test.txt’? y

使用 Journal 和 Inode 号恢复

注意,如果你删除文件后重启了系统,那么,相关的文件 journal 会丢失,我们也就无法恢复文件了。所以,恢复文件的前提是,Journal不能丢失,即,系统不能重启

因为我们已经知道 test.txt 文件的 inode 号是 15,所以我们可以使用 debugfs 命令来查看:

debugfs: logdump -i <15>
FS block 1006 logged at sequence 404351, journal block 7241
(inode block for inode 15):
Inode: 15 Type: regular Mode: 0664 Flags: 0×0 Generation: 0
User: 0 Group: 0 Size: 20
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0×48159f2d — Mon Apr 28 15:25:57 2008
atime: 0×48159f27 — Mon Apr 28 15:25:51 2008
mtime: 0×4806f070 — Thu Apr 17 12:08:40 2008
Blocks: (0+1): 10234
No magic number at block 7247: end of journal.


请注意上面信息中的这一行:

Blocks: (0+1): 10234

这就是inode 15存放文件的地址(数据块)。然后,我们知道了这个地址,我们就可以使用 dd 命令,把这个地址上的数据给取出来

切换至命令行:

#dd if=/dev/sda5 of=/tmp/test.txt bs=4096 count=1 skip= 10234
1+0 records in
1+0 records out
  • if 是输入的设备
  • of 是输出的设备.
  • bs 指定一个block的大小
  • count 说明有多少个block需要dump
  • skip 说明从开始的地方跳过 10234 个block,并从取下一个block的数据。此处的值是logdump中Blocks: (0+1): 10234的值

下面让我们看一下被恢复的文件:

$cat /tmp/test.txt
this is test file


当然,上面的文件恢复是基于我们知道文件的inode,可在现实中,我们并不知道这个信息,如果我们不知道inode,我们还可能恢复吗?是的,这是可能的,让我们来看一下如何恢复。

使用 Journal 和 文件名恢复

如果我们不知道文件的inode我们可能恢复吗?我可以告诉你,这是不可能的事情。不过我们有办法知道文件的inode号。下面让我们来看看怎么做到:

$rm mytest.txt
rm: remove write-protected regular file `mytest.txt’? y

注意,我们并不知道其inode号,但我们可以使用 debugfs 命令来查看(使用其 ls -d 选项)。

debugfs: ls -d
2 (12) .    2 (12) ..    11 (20) lost+found    2347777 (20) oss
<2121567> (20) mytest.txt   

你看文件名了吧,它的inode号是 <2121567> ,注意,被删除了的文件的inode都是用尖括号包起来的。

即然知道了inode号,那么我们就很容易恢复了(使用 logdump选项):

debugfs: logdump -i <2121567> #使用logdump -i <节点号>
Inode 2121567 is at group 65, block 2129985, offset 3840
Journal starts at block 1, transaction 405642
FS block 2129985 logged at sequence 405644, journal block 9
    (inode block for inode 2121567):
    Inode: 2121567   Type: bad type        Mode: 0000   Flags: 0×0   Generation: 0
    User:     0   Group:     0   Size: 0
    File ACL: 0    Directory ACL: 0
    Links: 0   Blockcount: 0
    Fragment: Address: 0    Number: 0    Size: 0
    ctime: 0×00000000 — Thu Jan 1 05:30:00 1970
    atime: 0×00000000 — Thu Jan 1 05:30:00 1970
    mtime: 0×00000000 — Thu Jan 1 05:30:00 1970
    Blocks:
FS block 2129985 logged at sequence 405648, journal block 64
    (inode block for inode 2121567):
    Inode: 2121567   Type: regular        Mode: 0664   Flags: 0×0   Generation: 913772093
    User:   100   Group:     0   Size: 31
    File ACL: 2130943    Directory ACL: 0
    Links: 1   Blockcount: 16
    Fragment: Address: 0    Number: 0    Size: 0
    ctime: 0×4821d5d0 — Wed May 7 21:46:16 2008
    atime: 0×4821d8be — Wed May 7 21:58:46 2008
    mtime: 0×4821d5d0 — Wed May 7 21:46:16 2008
    Blocks: (0+1): 2142216

上面有很多信息,让我们仔细地查看,你可以看到下面一行信息:

FS block 2129985 logged at sequence 405644, journal block 9

并且,其类型是:

Type: bad type

再仔细看一下文件的时间戳下面的Blocks: 什么也没有。那么,让我们看一下下一个block:

FS block 2129985 logged at sequence 405648, journal block 64
    (inode block for inode 2121567):

这一条Journal就有block信息了:

Blocks: (0+1): 2142216

这就是被删除文件的地址,让我们再次运行恢复命令:

$sudo dd if=/dev/sda5 of=/home/hchen/mytest_recovered.txt bs=4096 skip=2142216 count=1  #skip 的值是blocks(0+1)中的值。count一般是1

再让我们来检查一下文件内容:

$ cat mytest_recovered.txt
this is my test file
小结

好了,下面是我们的一些总结:


0. 执行df  命令获得删除文件所在的设备

1. 执行debugfs命令。

2. open 设备名称;例如 open /dev/sda10

3)使用 debugfs: ls -d 找到被删除文件的inode号。inode号是< >中的编号


4)使用 debugfs:logdump -i <inode号>     找到文件的数据块地址,赋给步骤5中的skip值。


5)切换至命令行,使用dd 命令把数据取出来存成文件。

sudo dd if=/dev/sda10 of=/home/B.py bs=4096 skip=129032  count=1



转载于:https://www.cnblogs.com/think1988/p/4628104.html

### 如何恢复Linux中使用 `rm -rf` 误删的文件 在 Linux 中,当文件被 `rm -rf` 命令删除时,实际上只是解除了文件名与其 inode 的链接关系。如果没有任何进程继续访问该文件,则数据可能会逐渐被新写入的数据覆盖而永久丢失。因此,在尝试恢复之前,应立即停止对存储设备的所有写操作以防止数据进一步损失。 #### 使用工具进行恢复 以下是几种常见的恢复方法及其适用场景: 1. **利用 `/proc` 文件系统恢复仍在运行进程中打开的文件** 如果目标文件仍然被某些进程占用(即这些进程仍持有对该文件的有效句柄),则可以通过读取 `/proc/[pid]/fd/` 下对应的文件描述符来获取原始内容[^4]。 2. **采用 extundelete 工具恢复已删除文件** 对于基于 Ext3Ext4 文件系统的磁盘分区来说,可以安装并配置 extundelete 软件来进行更深层次的数据检索工作。此过程通常涉及以下几个步骤: - 安装必要的依赖项以及编译环境; - 解压源码包并通过标准 GNU 构建流程完成程序部署; - 执行具体命令扫描指定目录下的历史记录以便定位所需资源[^3]。 ```bash sudo apt-get update && sudo apt-get install bzip2 e2fslibs-dev e2fsprogs gcc g++ wget http://zy-res.oss-cn-hangzhou.aliyuncs.com/server/extundelete-0.2.4.tar.bz2 tar -xvjf extundelete-0.2.4.tar.bz2 cd extundelete-0.2.4/ ./configure && make && sudo make install sudo umount /dev/sdXN # 替换 sdXN 为目标分区名称 sudo extundelete --restore-directory path/to/deleted/files /dev/sdXN ``` 3. **借助 debugfs 实现基础级别的修复尝试** 当其他高级解决方案不可行时,还可以考虑运用内置实用程序如 debugfs 来手动探索超级块中的未分配空间区域寻找残留痕迹[^2]。不过需要注意的是这种方法成功率较低且风险较大,建议仅作为最后手段试用。 4. **针对特定应用层对象实施定制化策略** 特定类型的数据库实例遭遇此类事故后可能需要专门设计应对措施。例如 Oracle 数据库可通过 RMAN 备份机制结合物理镜像重建技术实现最大程度上的业务连续保障;而对于 MySQL 则可依靠 binlog 日志回滚至事故发生前一刻状态等[^5]。 --- ### 注意事项 无论采取哪种方式都需要提前做好充分准备,并严格遵循以下原则以免造成二次损害: - 将受影响卷迅速卸载隔离保护起来; - 遵循只读模式操作所有相关介质直至确认无误为止; - 根据实际情况灵活调整选用方案组合达到最佳效果。 ```python import os os.system(&#39;sudo yum -y install bzip2 e2fsprogs-devel e2fsprogs gcc-c++ make&#39;) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值