使用debugfs恢复 Ext3文件系统`rm -rf /`误删除丢失的数据

本文介绍了一次在Linux环境下因误用rm命令导致的数据丢失事故及其恢复过程。通过使用debugfs等工具,详细记录了从发现问题到成功恢复数据的步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

From: http://hi.baidu.com/higkoo/blog/item/3b9b0709e3368ac53bc763df.html

最近项目紧,没多少时间写博客,只能长话短说了。这是一个由

rm -rf ./

rm -rf /

引发的故事。

一位同事在维护测试环境的时候不小心引发了上面的故事。可怜的是故事是由我来收场……

之前只是听运维的同事说以前遇到过这事,没想到这次撞到我头上了

首先想到的是进WinPE 用数据恢复工具找回数据,但试了几个,都是把数据恢复到另一个地方,而且保存方式是NTFS/FAT 格式的。这一来,Linux系统的文件权限丢了不说,服务器硬盘那么大,备份和还原一遍也不简单啊。

然后就开始尝试在Linux下恢复数据了,服务器硬盘真好,都可以热插拨。啥时候我的工作机也这么高档多好啊。没多想就把丢数据的硬盘挂到其它的服务器上了。

刚搜到debugfs 的时候,觉得很繁琐。听同事说用unrm ,试了几下,发现unrm 只支持ext2 文件系统,这也太老旧了吧。

然后找到了google的ext3grep ,操作时候是挺容易的。丢数据的这台服务器不是我安装的,分区使用了LVM ,根分区留了很大空间,另外分了个/var和/usr。大部分数据都在根分区下。用ext3grep很快恢复了小分区/var的数据,在/usr分区恢复的中途居然报错了。根分区压根就不能恢复,刚恢复就抛异常给我看

最后还是决定用debugfs ,毕竟是操作自带的,其它工具很多也是基于其上。

当然,最终结果是恢复成功了。把过程记录下来:

[higkoo@TestServer data]# debugfs /dev/sdb3
debugfs 1.39 (29-May-2006)
debugfs: lsdel
Inode Owner Mode Size Blocks Time deleted
4386690 0 120777 3 1/ 1 Thu Dec 10 14:30:08 2009
4386625 0 40755 4096 1/ 1 Thu Dec 10 14:34:18 2009
4386656 0 100755 801504 197/ 197 Thu Dec 10 14:34:18 2009
10573730 500 100600 23 1/ 1 Thu Dec 10 14:34:18 2009
4 deleted inodes found.

debugfs: stat <4386690>
Inode: 4386690 Type: symlink Mode: 0777 Flags: 0x0 Generation: 1633477069
User: 0 Group: 0 Size: 3
File ACL: 13501458 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4b209570 -- Thu Dec 10 14:30:08 2009
atime: 0x4b06680d -- Fri Nov 20 17:57:33 2009
mtime: 0x49a3f3d0 -- Tue Feb 24 21:19:12 2009
dtime: 0x4b209570 -- Thu Dec 10 14:30:08 2009
BLOCKS:
(0):7496052
TOTAL: 1

debugfs: mi <4386625>
Mode [040755]
User ID [0]
Group ID [0]
Size [4096]
Creation time [1260426608]
Modification time [1260426608]
Access time [1260426608]
Deletion time [1260426858] 0
Link count [0]
1
Block count [16]
File flags [0x0]
Generation [0x615cdd53]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [4407296]
Direct Block #1 [0]
Direct Block #2 [0]
Direct Block #3 [0]
Direct Block #4 [0]
Direct Block #5 [0]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]

[root@pSrv6 data]# fsck /dev/sdb3
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/ contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 4386625, i_blocks is 16, should be 8. Fix<y>? yes

Inode 4386690, i_blocks is 0, should be 8. Fix<y>? yes

Inode 4386656, i_blocks is 1584, should be 1576. Fix<y>? yes

Deleted inode 10573729 has zero dtime. Fix<y>? yes

Inode 10573730, i_blocks is 16, should be 8. Fix<y>? yes

Extended attribute block 13501458 has reference count 107, should be 108. Fix<y>? yes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity
Unconnected directory inode 4386625 (/???)
Connect to /lost+found<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 26, should be 27. Fix<y>? yes

Unattached inode 4386656
Connect to /lost+found<y>? yes

Inode 4386656 ref count is 2, should be 1. Fix<y>? yes

Unattached inode 4386690
Connect to /lost+found<y>? yes

Inode 4386690 ref count is 2, should be 1. Fix<y>? yes

Unattached inode 10573730
Connect to /lost+found<y>? yes

Inode 10573730 ref count is 2, should be 1. Fix<y>? yes

Pass 5: Checking group summary information
yBlock bitmap differences: +4407296 +(4416420--4416616) +10592260
Fix<y>? yes

Free blocks count wrong for group #134 (1880, counted=1682).
Fix<y>? yes

Free blocks count wrong for group #323 (31742, counted=31741).
Fix<y>? yes

Free blocks count wrong (9979230, counted=9979031).
Fix<y>? yes

Inode bitmap differences: +4386625 +4386656 +4386690 +10573730
Fix<y>? yes

Free inodes count wrong for group #134 (32736, counted=32733).
Fix<y>? yes

Directories count wrong for group #134 (0, counted=1).
Fix<y>? yes

Free inodes count wrong for group #323 (32735, counted=32734).
Fix<y>? yes

Free inodes count wrong (24226297, counted=24226293).
Fix<y>? yes


/: ***** FILE SYSTEM WAS MODIFIED *****
/: 63819/24290112 files (5.2% non-contiguous), 14307232/24286263 blocks

搞定,呵呵!

没时间多说,留个思路以备忘……

### 如何恢复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、付费专栏及课程。

余额充值