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

最新推荐文章于 2022-10-22 08:08:32 发布

iteye_11539

最新推荐文章于 2022-10-22 08:08:32 发布

阅读量328

点赞数

文章标签：运维

本文介绍了一次在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