标签归档：ext3grep

我们都知道误删除文件后，如果没有其他操作，且数据库没有crash（句柄还在），那么是可以通过fd找到文件进行数据库恢复的，具体可以参考以前的文章：linux 误删除文件恢复 那么，如果句柄已经释放（比如数据库crash了），且客户重启了数据库，并执行了一些“恢复”尝试，然后怎么办？ 我们测试下，这里我们要借助一个小工具：ext3grep 该工具可以在下面的网址下载最新版： http://code.google.com/p/ext3grep/downloads/list 系统必须要有e2fsprogs-libs，否则安装ext3grep的时可能会有问题。 如果你下载了rpm包，那么安装so easy: 如果你下载了src的源码，那么可以如下方式安装： 我们看下他的帮助，还是很强大的： 模拟数据库文件被误删除，且数据库crash： 数据库启动报错，丢失了文件 ‘/oradata/orcl/users01.dbf’。 现在使用ext3grep进行扫描和恢复： ext3grep是针对ext3文件系统的（ext2单有自己的扫描恢复工具），确认丢失的文件是ext3文件体系: 这里，我的数据文件都在/oradata，是设备 /dev/sdc1 ： 注意这里，我的数据库目录的inode是 4358145 ，下面我们开始从这个inode继续查找： 文件的inode已经被覆盖了 这里根据两个两个信息进行恢复文件的操作： （1）数据库报错告诉我们需要恢复的文件名称：/oradata/orcl/users01.dbf （2）ext3grep的提示信息告诉我们了从哪里开始写文件： Inode 4358145 is directory “orcl”. 恢复过程如下： 从上面提示我们看到了文件已经恢复出来了，放在 orcl/RESTORED_FILES 下面： 完了不行了，被覆盖了。。。否则这一步就会在当前执行ext3grep的目录下找到一个RESTORED_FILES目录，里面就是我们的user01.dbf文件，再之后，你懂的。。 把他copy到/oradata/orcl/users01.dbf，然后执行recover datafile ‘/oradata/orcl/users01.dbf’，在open，就ok了。。。 我们再测试另一个工具extundelete（感觉原理跟ext3grep一样），看看他是不是强大一些，o(∩_∩)o … 继续阅读 →