搜索了半天, 找到了一款开源软件——ext3grep。 专注于ext3格式的文件系统的数据系统分析
下载地址:
下面就开始数据恢复了。
首先要卸载掉需要恢复数据的分区, 如果是根目录,就需要把分区设置成只读,这一步一定要第一时间做, 不能让磁盘日志文件和源数据被覆盖掉, 不然就真的万劫不复了!!。
使用方式比较简单 ,接下来按以下博客的步骤去做就可以了。
下面着重记录一下我遇到的问题,就当做个笔记吧:
1.
ext3grep-0.2.0 - ext3grep.cc:4130: bool init_directories_action(): Assertion `first_block != -1' failed. |
如果报错记得删除 ext3grep执行目录 下的 sda2.ext3grep.stage* , 其中的sda2是我的分区。
这个问题还导致了其他错误,不过具体不记得出错点了,总之如果时间不是很紧张的话, 做下一个命令前 记得删sda2.ext3grep.stage*就好了
2. ext3grep: init_directories.cc:534: void init_directories(): Assertion `lost_plus_found_directory_iter != all_directories.end()' failed.
关于这个问题, 作者给出了一个patch:
The patch is basically changing the line:
ASSERT(lost_plus_found_directory_iter != all_directories.end());
to read
if (lost_plus_found_directory_iter != all_directories.end())
{
and then add a ending } where appropriate.
但是在最新的源码当中, 并没有这个源码, 并且 add a ending } where appropriate 也不知道哪里 appropriate......
简单看了一下代码, 大致是要在分析的分区内找“lost+found” 文件夹。 所以新建一个lost+found 就解决了。
3.Assertion `device.good()' failed (in get_block.cc:37)
解决方法: 选择一个足够大的分区来存储恢复的文件。
最后, 数据恢复了80% 左右 (删除目录的时候,另一个ssh窗口正在下载,可能覆盖了一部分数据), 其中涉及我的代码的有两个文件没恢复过来, 都是改动不太大的文件, 花点时间就能改回来。 比较麻烦的是整个工作环境都乱了,需要花一定的时间重新配置搭建起来,不过已经算是不幸中的万幸了。
后话: 数据恢复毕竟只是事后补救的措施, 只有及时备份才能防范于未然, 以后写个脚本每天备份, 立日志为鉴!