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
搞定，呵呵！
没时间多说，留个思路以备忘……