Linux下恢复删除的文件

作者: tiankonguse | 更新日期: 2015-09-13 16:05:00

周五发生了好几件事,有必要简单的记录一下.

前言的前言

最近在忙一些没有意义的东西:收集互联网数据,什么CSND账号呀, QQ群关系呀, 12306账号呀什么的.后果是我那 cache 的关键一篇记录迟迟没有写出来, 算了, 收集数据的事暂时不做了, 下周抽时间继续做cache的事情吧.

前言

9月11日, 周五, 好声音又要开始了.

下午, DBA找我说有些SQL执行了两个小时了,导致主从同步延迟很多.

晚上, 一个同事要走了, 做了一个月的项目要整理一下好交接出去.结果删除没有用的文件时, 路径多了一个空格, 导致整个项目的代码被删除, 坑爹的是他从来没提交过SVN.

奋斗到天亮

那位同事误删项目时, 我以为是清除cmake的临时文件时误操作的, 结果是管理项目时误操作导致的.比如有个 bulid 目录, 你想删除 bulid 下的东西, 一般是进入bulid目录, 然后删除即可.

kyyuan@skyyuan-PC3:test $ tree . ├── bulid │   └── tml └── file  1 directory, 2 files  skyyuan@skyyuan-PC3:test $ cd bulid/  skyyuan@skyyuan-PC3:bulid $ rm -rf *  skyyuan@skyyuan-PC3:bulid $ cd ..  skyyuan@skyyuan-PC3:test $ tree . ├── bulid └── file  1 directory, 1 file 

但是这位同事没有进入到相关目录, 然后通过路径来删除的.

skyyuan@skyyuan-PC3:test $ touch bulid/tmp  skyyuan@skyyuan-PC3:test $ tree . ├── bulid │   └── tmp └── file  1 directory, 2 files  skyyuan@skyyuan-PC3:test $ rm -rf bulid/*  skyyuan@skyyuan-PC3:test $ tree . ├── bulid └── file  1 directory, 1 file 

那样虽然可以做到删除文件, 但是如果不小心在星号前面多打了一个空格, 后果不堪设想.

skyyuan@skyyuan-PC3:test $ touch bulid/tmp  skyyuan@skyyuan-PC3:test $ tree . ├── bulid │   └── tmp └── file  1 directory, 2 files  skyyuan@skyyuan-PC3:test $ rm -rf bulid/ *  skyyuan@skyyuan-PC3:test $ tree .  0 directories, 0 files 

大概这位同事在管理项目时, 就是类似的发生悲剧的.

不过幸运的是, 这台机器有两个磁盘, 系统在小磁盘上, 数据在大磁盘上.这里可以把大磁盘卸载了, 来慢慢恢复数据.

root@10.123.10.23:[~]: parted --list Disk /dev/vda: 19.3GB  Number  Start   End     Size    Type     File system  标志  1      32.3kB  9994MB  9994MB  primary  ext3         启动  2      9994MB  12.1GB  2147MB  primary  3      12.1GB  19.3GB  7181MB  primary   Disk /dev/vdb: 195GB  Number  Start   End    Size   Type     File system  标志  1      32.3kB  195GB  195GB  primary  ext3 

网上搜索linux文件恢复, 搜到的都是foremost, extundelete, scalpel, testdisk, phtorec 等相关教程.

试了之后发现都不理想, 后来加上 ext3 这个关键字, 搜到了 ext3grep 这个工具.

然后下载源码安装.

wget https://ext3grep.googlecode.com/files/ext3grep-0.10.2.tar.gz tar zxvf ext3grep-0.10.1.tar.gz cd ext3grep-0.10.1 ./configure make make install 

然后卸载磁盘.

 root@10.123.10.23:[/]: df -k 文件系统             1K-块      已用      可用 已用% 挂载点 /dev/vda1              9606084   5634124   3483988  62% / tmpfs                  8085312       880   8084432   1% /dev/shm /dev/vdb1            187846260  88430136  89874096  50% /data  root@10.123.10.23:[/]: fuser -k /data root@10.123.10.23:[/]: umount /data 

然后扫描磁盘上的所有节点.大概会跑几十分钟吧.

root@10.123.10.23:[/]: ext3grep /dev/vdb1 --ls --inode 2 Running ext3grep version 0.10.2 WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is. WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set. This either means that your partition is still mounted, and/or the file system is in an unclean state. Number of groups: 1456 Loading group metadata... done Minimum / maximum journal block: 23790082 / 23823397 Loading journal descriptors... sorting... done ... ... 

看着节点一个一个的扫描, 心里面逐渐的稳定下来.

突然发现这样一个错误:

WARNING: Failed to open file 'locate_output'. See locate.cc ERROR: dir_inode_to_block(1589385) returned -1. ext3grep: init_directories.cc:82: bool init_directories_action(const ext3_dir_entry_2&, const Inode&, bool, bool, bool, bool, bool, bool, Parent*, void*): Assertion . 已放弃 

root@10.123.10.23:[/recovery]: ll 总用量 2808 -rw-r--r-- 1 root root  124904  9月 13 18:08 scan.log -rw-r--r-- 1 root root 2737031  9月 13 17:27 vdb1.ext3grep.stage1  root@10.123.10.23:[/recovery]: mv vdb1.ext3grep.stage1 vdb1.ext3grep.stage1.bak01  root@10.123.10.23:[/recovery]: ll 总用量 2808 -rw-r--r-- 1 root root  124904  9月 13 18:08 scan.log -rw-r--r-- 1 root root 2737031  9月 13 17:27 vdb1.ext3grep.stage1.bak01  root@10.123.10.23:[/recovery]: ext3grep /dev/vdb1 --accept-all --ls --inode 2  > scan.log WARNING: Failed to open file 'locate_output'. See locate.cc  root@10.123.10.23:[/recovery]:  

然后一般我们是根据名字来恢复文件的, 所以我们需要先找到我们的文件.

root@10.123.10.23:[/home/skyyuan/test]: ll screenshot_hash.cpp  -rwxr--r-- 1 skyyuan users 730  9月  9 11:01 screenshot_hash.cpp  root@10.123.10.23:[/recovery]: ext3grep  /dev/vdb1 --dump-names | grep screenshot_hash.cpp skyyuan/skyyuan/.vim/view/~=+test=+screenshot_hash.cpp= skyyuan/test/screenshot_hash.cpp skyyuan/test/screenshot_hash.cpp~ 

这个时候我们可以搜索可以恢复的文件路径, 然后恢复之.

root@10.123.10.23:[/recovery]: ext3grep /dev/vdb1 --restore-file skyyuan/test/screenshot_hash.cpp Running ext3grep version 0.10.2 WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is. WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set. This either means that your partition is still mounted, and/or the file system is in an unclean state. Number of groups: 1456 Minimum / maximum journal block: 23790082 / 23823397 Loading journal descriptors... sorting... done The oldest inode block that is still in the journal, appears to be from 13246709 = Wed Jun  3 15:38:29 1970 Journal transaction 884563 wraps around, some data blocks might have been lost of this transaction. Number of descriptors in journal: 31536; min / max sequence numbers: 883887 / 885058 Writing output to directory RESTORED_FILES/ Loading vdb1.ext3grep.stage2.........................................................................................................................................e Restoring skyyuan/test/screenshot_hash.cpp  root@10.123.10.23:[/recovery]: ll 总用量 16992 drwxr-xr-x 3 root root     4096  9月 13 18:23 RESTORED_FILES -rw-r--r-- 1 root root   325248  9月 13 18:19 scan.log -rw-r--r-- 1 root root  2737059  9月 13 18:18 vdb1.ext3grep.stage1 -rw-r--r-- 1 root root  2737031  9月 13 17:27 vdb1.ext3grep.stage1.bak01 -rw-r--r-- 1 root root 11554133  9月 13 18:19 vdb1.ext3grep.stage2  root@10.123.10.23:[/recovery]: ll RESTORED_FILES 总用量 4 drwxr-x--- 3 root root 4096  9月 13 18:23 skyyuan root@10.123.10.23:[/recovery]: tree RESTORED_FILES/ RESTORED_FILES/ └── skyyuan     └── test         └── screenshot_hash.cpp  2 directories, 1 file 

恢复完了, 我们再把磁盘挂上去.

mount /dev/vdb1 /data 

最后, 在编译程序, 运行之后发现正常, 什么也不管, 赶紧提交SVN.

尾记

这个周五, 一直忙到半夜2点多才回去, 这些事故与问题实际上和我都没有关系, 但是加入进来学到不少东西.

ext3grep 的源码我已经在我的github上存了一份, 对源码感兴趣的可以来看看.