文件恢复工具extundelete官网：http://extundelete.sourceforge.net/
使用方法，在页面里找到download，下载源码安装包：extundelete-0.2.4.tar.bz2
安装：
[root@localhost extundelete-0.2.4]# yum -y install e2fsprogs-libs e2fsprogs e2fsprogs-devel [root@localhost extundelete-0.2.4]# rpm -q e2fsprogs-libs e2fsprogs e2fsprogs-devel [root@localhost extundelete-0.2.4]# tar jxvf extundelete-0.2.4.tar.bz2 [root@localhost extundelete-0.2.4]# cd extundelete-0.2.4 [root@localhost extundelete-0.2.4]#extundelete-0.2.4]# ./configure && make && make install
使用：
#查看能恢复的数据： [root@localhost ~]# extundelete /dev/sdc1 --inode 2 #恢复单个文件 [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 ... 1600 groups loaded. Loading journal descriptors ... 176 descriptors loaded. *** Error in `./extundelete': double free or corruption (!prev): 0x000000000141efd0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7c619)[0x7f84baff0619] ./extundelete[0x40ce6b] ./extundelete[0x40ff86] ./extundelete[0x404654] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f84baf95c05] ./extundelete[0x404b8f] ======= Memory map: ======== 00400000-0041c000 r-xp 00000000 fd:02 659238 /home/wangdong/extundel/extundelete-0.2.4/src/extundelete 0061c000-0061d000 r--p 0001c000 fd:02 659238 /home/wangdong/extundel/extundelete-0.2.4/src/extundelete 0061d000-0061e000 rw-p 0001d000 fd:02 659238 /home/wangdong/extundel/extundelete-0.2.4/src/extundelete 0061e000-0061f000 rw-p 00000000 00:00 0 013fd000-0143f000 rw-p 00000000 00:00 0 [heap] 7f84b4000000-7f84b4021000 rw-p 00000000 00:00 0 7f84b4021000-7f84b8000000 ---p 00000000 00:00 0 7f84ba717000-7f84bad58000 rw-p 00000000 00:00 0 7f84bad58000-7f84bad6f000 r-xp 00000000 fd:00 201371296 /usr/lib64/libpthread-2.17.so 7f84bad6f000-7f84baf6e000 ---p 00017000 fd:00 201371296 /usr/lib64/libpthread-2.17.so 7f84baf6e000-7f84baf6f000 r--p 00016000 fd:00 201371296 /usr/lib64/libpthread-2.17.so 7f84baf6f000-7f84baf70000 rw-p 00017000 fd:00 201371296 /usr/lib64/libpthread-2.17.so 7f84baf70000-7f84baf74000 rw-p 00000000 00:00 0 7f84baf74000-7f84bb12c000 r-xp 00000000 fd:00 201328485 /usr/lib64/libc-2.17.so 7f84bb12c000-7f84bb32c000 ---p 001b8000 fd:00 201328485 /usr/lib64/libc-2.17.so 7f84bb32c000-7f84bb330000 r--p 001b8000 fd:00 201328485 /usr/lib64/libc-2.17.so 7f84bb330000-7f84bb332000 rw-p 001bc000 fd:00 201328485 /usr/lib64/libc-2.17.so 7f84bb332000-7f84bb337000 rw-p 00000000 00:00 0 7f84bb337000-7f84bb34c000 r-xp 00000000 fd:00 203151519 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f84bb34c000-7f84bb54b000 ---p 00015000 fd:00 203151519 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f84bb54b000-7f84bb54c000 r--p 00014000 fd:00 203151519 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f84bb54c000-7f84bb54d000 rw-p 00015000 fd:00 203151519 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f84bb54d000-7f84bb64e000 r-xp 00000000 fd:00 201328494 /usr/lib64/libm-2.17.so 7f84bb64e000-7f84bb84d000 ---p 00101000 fd:00 201328494 /usr/lib64/libm-2.17.so 7f84bb84d000-7f84bb84e000 r--p 00100000 fd:00 201328494 /usr/lib64/libm-2.17.so 7f84bb84e000-7f84bb84f000 rw-p 00101000 fd:00 201328494 /usr/lib64/libm-2.17.so 7f84bb84f000-7f84bb938000 r-xp 00000000 fd:00 201371650 /usr/lib64/libstdc++.so.6.0.19 7f84bb938000-7f84bbb37000 ---p 000e9000 fd:00 201371650 /usr/lib64/libstdc++.so.6.0.19 7f84bbb37000-7f84bbb3f000 r--p 000e8000 fd:00 201371650 /usr/lib64/libstdc++.so.6.0.19 7f84bbb3f000-7f84bbb41000 rw-p 000f0000 fd:00 201371650 /usr/lib64/libstdc++.so.6.0.19 7f84bbb41000-7f84bbb56000 rw-p 00000000 00:00 0 7f84bbb56000-7f84bbb98000 r-xp 00000000 fd:00 201372415 /usr/lib64/libext2fs.so.2.4 7f84bbb98000-7f84bbd98000 ---p 00042000 fd:00 201372415 /usr/lib64/libext2fs.so.2.4 7f84bbd98000-7f84bbd99000 r--p 00042000 fd:00 201372415 /usr/lib64/libext2fs.so.2.4 7f84bbd99000-7f84bbd9b000 rw-p 00043000 fd:00 201372415 /usr/lib64/libext2fs.so.2.4 7f84bbd9b000-7f84bbd9e000 r-xp 00000000 fd:00 201371665 /usr/lib64/libcom_err.so.2.1 7f84bbd9e000-7f84bbf9d000 ---p 00003000 fd:00 201371665 /usr/lib64/libcom_err.so.2.1 7f84bbf9d000-7f84bbf9e000 r--p 00002000 fd:00 201371665 /usr/lib64/libcom_err.so.2.1 7f84bbf9e000-7f84bbf9f000 rw-p 00003000 fd:00 201371665 /usr/lib64/libcom_err.so.2.1 7f84bbf9f000-7f84bbfc0000 r-xp 00000000 fd:00 201328478 /usr/lib64/ld-2.17.so 7f84bbfd6000-7f84bc1ae000 rw-p 00000000 00:00 0 7f84bc1bd000-7f84bc1c0000 rw-p 00000000 00:00 0 7f84bc1c0000-7f84bc1c1000 r--p 00021000 fd:00 201328478 /usr/lib64/ld-2.17.so 7f84bc1c1000-7f84bc1c2000 rw-p 00022000 fd:00 201328478 /usr/lib64/ld-2.17.so 7f84bc1c2000-7f84bc1c3000 rw-p 00000000 00:00 0 7ffc13f68000-7ffc13f89000 rw-p 00000000 00:00 0 [stack] 7ffc13fc8000-7ffc13fca000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
磁盘本身SSD的，用VMWare虚拟机虚拟出来的磁盘，挂载到系统上，用mkfs.ext4格式化成了ext4，也mount上去，写了文件，然后删除，然后umount，然后恢复，结果竟然挂了。官网说依赖包“ensure you have e2fsprogs version 1.41 or newer”，我的也符合要求啊。
[root@localhost extundelete-0.2.4]# rpm -qa | grep e2fsprogs e2fsprogs-devel-1.42.9-13.el7.x86_64 e2fsprogs-libs-1.42.9-13.el7.x86_64 e2fsprogs-1.42.9-13.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.6756 (gdb) bt #0 0x00007f80061a71f7 in raise () from /lib64/libc.so.6 #1 0x00007f80061a88e8 in abort () from /lib64/libc.so.6 #2 0x00007f80061e6f47 in __libc_message () from /lib64/libc.so.6 #3 0x00007f80061ee619 in _int_free () from /lib64/libc.so.6 #4 0x000000000040ce6b in init_journal (fs=fs@entry=0x1f8e0a0, jfs=0x1f8e0a0, jsb=jsb@entry=0x7fffdea06aa0) at extundelete.cc:1167 #5 0x000000000040ff86 in examine_fs (fs=0x1f8e0a0) at cli.cc:287 #6 0x0000000000404654 in main (argc=1, argv=0x7fffdea07088) at cli.cc:806 (gdb)
最终出错在extundelete.cc:1167，恕本人才疏学浅，gdb各种运行跟踪打断点，也没看出代码有什么问题，根据报错的情况可以大概猜测“应该是某种原因导致一开始new的指针类型发生了变化，导致delete的时候释放越界导致的，并非是多次释放指针造成的”。想想只是实验一下功能，一次性的，那我直接在最后return掉，不释放内存，行不行
1163 Log::debug << std::endl; 1164 } 1165 return 0; 1166 1167 finally: 1168 delete[] buf; 1169 delete[] descbuf; 1170 delete[] blocks;
结果这一关过了，下一关又卡住了
(gdb) bt #0 0x00007fef076451f7 in raise () from /lib64/libc.so.6 #1 0x00007fef076468e8 in abort () from /lib64/libc.so.6 #2 0x00007fef07684f47 in __libc_message () from /lib64/libc.so.6 #3 0x00007fef0768c619 in _int_free () from /lib64/libc.so.6 #4 0x00007fef0820e716 in ext2fs_free () from /lib64/libext2fs.so.2 #5 0x00007fef082092d7 in ext2fs_close2 () from /lib64/libext2fs.so.2 #6 0x000000000040466a in main (argc=1, argv=0x7ffe9c53c598) at cli.cc:812
我不closefs行不行
812 //errcode = ext2fs_close (fs); 813 if (errcode) { 814 com_err(Config::progname.c_str(), errcode, "when trying to close filesystem"); 815 }
结果，虽然不coredump了，但是也没成功：(RECOVERED_FILES一个文件都没有)
[root@localhost src]# ./extundelete /dev/sdc1 --restore-all NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 1600 groups loaded. Loading journal descriptors ... 176 descriptors loaded. Searching for recoverable inodes in directory / ... 0 recoverable inodes found. Looking through the directory structure for deleted files ... 0 recoverable inodes still lost. No files were undeleted.
但我磁盘中本身是有文件的：
[root@localhost src]# extundelete /dev/sdc1 --inode 2 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 1600 groups loaded. Group: 0 Contents of inode 2: 0000 | ed 41 00 00 00 10 00 00 ff 39 40 5c 0c 3a 40 5c | .A.......9@.:@ 0010 | 0c 3a 40 5c 00 00 00 00 00 00 03 00 08 00 00 00 | .:@............ 0020 | 00 00 08 00 04 00 00 00 0a f3 01 00 04 00 00 00 | ................ 0030 | 00 00 00 00 00 00 00 00 01 00 00 00 3a 24 00 00 | ............:$.. 0040 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0050 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0060 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 0080 | 1c 00 00 00 f0 32 f5 62 f0 32 f5 62 1c db be 52 | .....2.b.2.b...R 0090 | 74 36 40 5c 00 00 00 00 00 00 00 00 00 00 00 00 | t6@............ 00a0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00b0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00c0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00d0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00e0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00f0 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ Inode is Allocated File mode: 16877 Low 16 bits of Owner Uid: 0 Size in bytes: 4096 Access time: 1547713023 Creation time: 1547713036 Modification time: 1547713036 Deletion Time: 0 Low 16 bits of Group Id: 0 Links count: 3 Blocks count: 8 File flags: 524288 File version (for NFS): 0 File ACL: 0 Directory ACL: 0 Fragment address: 0 Direct blocks: 127754, 4, 0, 0, 1, 9274, 0, 0, 0, 0, 0, 0 Indirect block: 0 Double indirect block: 0 Triple indirect block: 0 File name | Inode number | Deleted status . 2 .. 2 lost+found 11 test 2883585 Deleted
由于没有研究过ext4文件系统相关的东西，因此此问题也没看出什么眉目，目前也不急于使用这个功能，问题也没有解决，待之后研究出结果之后出来结帖。
本人测试所使用的系统：
[root@ceph01 src]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) [root@ceph01 src]# uname -a Linux ceph01 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
唉。。。。。。