文件恢复工具extundelete官网：http://extundelete.sourceforge.net/
使用方法，在页面里找到download，下载源码安装包：extundelete-0.2.4.tar.bz2
安装：
[root@localhost extundelete-0.2.]# yum -y install e2fsprogs-libs e2fsprogs e2fsprogs-devel
[root@localhost extundelete-0.2.]# rpm -q e2fsprogs-libs e2fsprogs e2fsprogs-devel
[root@localhost extundelete-0.2.]# tar jxvf extundelete-0.2..tar.bz2
[root@localhost extundelete-0.2.]# cd extundelete-0.2.
[root@localhost extundelete-0.2.]#extundelete-0.2.]# ./configure && make && make install
使用：
#查看能恢复的数据：
[root@localhost ~]# extundelete /dev/sdc1 --inode
#恢复单个文件
[root@localhost ~]# extundelete /dev/sdc1 --restore-file somefile
#恢复目录
[root@localhost ~]# extundelete /dev/sdc1 --restore-directory /somedir
#恢复所有文件
[root@localhost ~]# extundelete /dev/sdb1 --restore-all
使用步骤不再赘述，详情请参考别人博客：https://www.cnblogs.com/yuhuLin/p/7027253.html
但是让我郁闷的是测试的时候居然报错了：(而且问题我也没有解决，如果着急就别往下看了)
报错的是Centos7.4 + SSD硬盘 + ext4，但是找了另外一个Centos7 +SAS+ext4的硬盘恢复成功了，看来恢复工具也不是万能的，数据无价，谨慎操作才是根本。
[root@ceph01 src]# ./extundelete /dev/sdc1 --restore-all
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... groups loaded.
Loading journal descriptors ... descriptors loaded.
*** Error in `./extundelete': double free or corruption (!prev): 0x000000000141efd0 ***
======= Backtrace: =========
/lib64/libc.so.(+0x7c619)[0x7f84baff0619]
./extundelete[0x40ce6b]
./extundelete[0x40ff86]
./extundelete[0x404654]
/lib64/libc.so.(__libc_start_main+0xf5)[0x7f84baf95c05]
./extundelete[0x404b8f]
======= Memory map: ========
-0041c000 r-xp fd: /home/wangdong/extundel/extundelete-0.2./src/extundelete
0061c000-0061d000 r--p 0001c000 fd: /home/wangdong/extundel/extundelete-0.2./src/extundelete
0061d000-0061e000 rw-p 0001d000 fd: /home/wangdong/extundel/extundelete-0.2./src/extundelete
0061e000-0061f000 rw-p :
013fd000-0143f000 rw-p : [heap]
7f84b4000000-7f84b4021000 rw-p :
7f84b4021000-7f84b8000000 ---p :
7f84ba717000-7f84bad58000 rw-p :
7f84bad58000-7f84bad6f000 r-xp fd: /usr/lib64/libpthread-2.17.so
7f84bad6f000-7f84baf6e000 ---p fd: /usr/lib64/libpthread-2.17.so
7f84baf6e000-7f84baf6f000 r--p fd: /usr/lib64/libpthread-2.17.so
7f84baf6f000-7f84baf70000 rw-p fd: /usr/lib64/libpthread-2.17.so
7f84baf70000-7f84baf74000 rw-p :
7f84baf74000-7f84bb12c000 r-xp fd: /usr/lib64/libc-2.17.so
7f84bb12c000-7f84bb32c000 ---p 001b8000 fd: /usr/lib64/libc-2.17.so
7f84bb32c000-7f84bb330000 r--p 001b8000 fd: /usr/lib64/libc-2.17.so
7f84bb330000-7f84bb332000 rw-p 001bc000 fd: /usr/lib64/libc-2.17.so
7f84bb332000-7f84bb337000 rw-p :
7f84bb337000-7f84bb34c000 r-xp fd: /usr/lib64/libgcc_s-4.8.-.so.
7f84bb34c000-7f84bb54b000 ---p fd: /usr/lib64/libgcc_s-4.8.-.so.
7f84bb54b000-7f84bb54c000 r--p fd: /usr/lib64/libgcc_s-4.8.-.so.
7f84bb54c000-7f84bb54d000 rw-p fd: /usr/lib64/libgcc_s-4.8.-.so.
7f84bb54d000-7f84bb64e000 r-xp fd: /usr/lib64/libm-2.17.so
7f84bb64e000-7f84bb84d000 ---p fd: /usr/lib64/libm-2.17.so
7f84bb84d000-7f84bb84e000 r--p fd: /usr/lib64/libm-2.17.so
7f84bb84e000-7f84bb84f000 rw-p fd: /usr/lib64/libm-2.17.so
7f84bb84f000-7f84bb938000 r-xp fd: /usr/lib64/libstdc++.so.6.0.
7f84bb938000-7f84bbb37000 ---p 000e9000 fd: /usr/lib64/libstdc++.so.6.0.
7f84bbb37000-7f84bbb3f000 r--p 000e8000 fd: /usr/lib64/libstdc++.so.6.0.
7f84bbb3f000-7f84bbb41000 rw-p 000f0000 fd: /usr/lib64/libstdc++.so.6.0.
7f84bbb41000-7f84bbb56000 rw-p :
7f84bbb56000-7f84bbb98000 r-xp fd: /usr/lib64/libext2fs.so.2.4
7f84bbb98000-7f84bbd98000 ---p fd: /usr/lib64/libext2fs.so.2.4
7f84bbd98000-7f84bbd99000 r--p fd: /usr/lib64/libext2fs.so.2.4
7f84bbd99000-7f84bbd9b000 rw-p fd: /usr/lib64/libext2fs.so.2.4
7f84bbd9b000-7f84bbd9e000 r-xp fd: /usr/lib64/libcom_err.so.2.1
7f84bbd9e000-7f84bbf9d000 ---p fd: /usr/lib64/libcom_err.so.2.1
7f84bbf9d000-7f84bbf9e000 r--p fd: /usr/lib64/libcom_err.so.2.1
7f84bbf9e000-7f84bbf9f000 rw-p fd: /usr/lib64/libcom_err.so.2.1
7f84bbf9f000-7f84bbfc0000 r-xp fd: /usr/lib64/ld-2.17.so
7f84bbfd6000-7f84bc1ae000 rw-p :
7f84bc1bd000-7f84bc1c0000 rw-p :
7f84bc1c0000-7f84bc1c1000 r--p fd: /usr/lib64/ld-2.17.so
7f84bc1c1000-7f84bc1c2000 rw-p fd: /usr/lib64/ld-2.17.so
7f84bc1c2000-7f84bc1c3000 rw-p :
7ffc13f68000-7ffc13f89000 rw-p : [stack]
7ffc13fc8000-7ffc13fca000 r-xp : [vdso]
ffffffffff600000-ffffffffff601000 r-xp : [vsyscall]
磁盘本身SSD的，用VMWare虚拟机虚拟出来的磁盘，挂载到系统上，用mkfs.ext4格式化成了ext4，也mount上去，写了文件，然后删除，然后umount，然后恢复，结果竟然挂了。官网说依赖包“ensure you have e2fsprogs version 1.41 or newer”，我的也符合要求啊。
[root@localhost extundelete-0.2.]# rpm -qa | grep e2fsprogs
e2fsprogs-devel-1.42.-.el7.x86_64
e2fsprogs-libs-1.42.-.el7.x86_64
e2fsprogs-1.42.-.el7.x86_64
为什么？看代码也不是很多，看看自己能不能定位出问题。
#打开core
[root@localhost src]# ulimit -c unlimited
#运行产生core文件
[root@localhost src]# ./extundelete /dev/sdc1 --restore-all
#调试运行后产生的core文件
[root@localhost src]# gdb extundelete core.
(gdb) bt
# 0x00007f80061a71f7 in raise () from /lib64/libc.so.
# 0x00007f80061a88e8 in abort () from /lib64/libc.so.
# 0x00007f80061e6f47 in __libc_message () from /lib64/libc.so.
# 0x00007f80061ee619 in _int_free () from /lib64/libc.so.
# 0x000000000040ce6b in init_journal (fs=fs@entry=0x1f8e0a0, jfs=0x1f8e0a0, jsb=jsb@entry=0x7fffdea06aa0) at extundelete.cc:
# 0x000000000040ff86 in examine_fs (fs=0x1f8e0a0) at cli.cc:
# 0x0000000000404654 in main (argc=, argv=0x7fffdea07088) at cli.cc:
(gdb)
最终出错在extundelete.cc:1167，恕本人才疏学浅，gdb各种运行跟踪打断点，也没看出代码有什么问题，根据报错的情况可以大概猜测“应该是某种原因导致一开始new的指针类型发生了变化，导致delete的时候释放越界导致的，并非是多次释放指针造成的”。想想只是实验一下功能，一次性的，那我直接在最后return掉，不释放内存，行不行
Log::debug << std::endl;
}
return ; finally:
delete[] buf;
delete[] descbuf;
delete[] blocks;
结果这一关过了，下一关又卡住了
(gdb) bt
# 0x00007fef076451f7 in raise () from /lib64/libc.so.
# 0x00007fef076468e8 in abort () from /lib64/libc.so.
# 0x00007fef07684f47 in __libc_message () from /lib64/libc.so.
# 0x00007fef0768c619 in _int_free () from /lib64/libc.so.
# 0x00007fef0820e716 in ext2fs_free () from /lib64/libext2fs.so.
# 0x00007fef082092d7 in ext2fs_close2 () from /lib64/libext2fs.so.
# 0x000000000040466a in main (argc=, argv=0x7ffe9c53c598) at cli.cc:
我不closefs行不行
//errcode = ext2fs_close (fs);
if (errcode) {
com_err(Config::progname.c_str(), errcode, "when trying to close filesystem");
}
结果，虽然不coredump了，但是也没成功：(RECOVERED_FILES一个文件都没有)
[root@localhost src]# ./extundelete /dev/sdc1 --restore-all
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... groups loaded.
Loading journal descriptors ... descriptors loaded.
Searching for recoverable inodes in directory / ...
recoverable inodes found.
Looking through the directory structure for deleted files ...
recoverable inodes still lost.
No files were undeleted.
但我磁盘中本身是有文件的：
[root@localhost src]# extundelete /dev/sdc1 --inode
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... groups loaded.
Group:
Contents of inode :
| ed ff 5c 0c 3a 5c | .A.......@\.:@\
| 0c 3a 5c | .:@\............
| 0a f3 | ................
| 3a | ............:$..
| | ................
| | ................
| | ................
| | ................
| 1c f0 f5 f0 f5 1c db be | ......b..b...R
| 5c | t6@\............
00a0 | | ................
00b0 | | ................
00c0 | | ................
00d0 | | ................
00e0 | | ................
00f0 | | ................ Inode is Allocated
File mode:
Low bits of Owner Uid:
Size in bytes:
Access time:
Creation time:
Modification time:
Deletion Time:
Low bits of Group Id:
Links count:
Blocks count:
File flags:
File version (for NFS):
File ACL:
Directory ACL:
Fragment address:
Direct blocks: , , , , , , , , , , ,
Indirect block:
Double indirect block:
Triple indirect block: File name | Inode number | Deleted status
.
..
lost+found
test Deleted
由于没有研究过ext4文件系统相关的东西，因此此问题也没看出什么眉目，目前也不急于使用这个功能，问题也没有解决，待之后研究出结果之后出来结帖。
本人测试所使用的系统：
[root@ceph01 src]# cat /etc/redhat-release
CentOS Linux release 7.4. (Core)
[root@ceph01 src]# uname -a
Linux ceph01 3.10.-693.2..el7.x86_64 # SMP Tue Sep :: UTC x86_64 x86_64 x86_64 GNU/Linux
唉。。。。。。