我们都知道误删除文件后，如果没有其他操作，且数据库没有crash（句柄还在），那么是可以通过fd找到文件进行数据库恢复的，具体可以参考以前的文章：linux 误删除文件恢复
那么，如果句柄已经释放（比如数据库crash了），且客户重启了数据库，并执行了一些“恢复”尝试，然后怎么办？
我们测试下，这里我们要借助一个小工具：ext3grep
该工具可以在下面的网址下载最新版：
http://code.google.com/p/ext3grep/downloads/list
系统必须要有e2fsprogs-libs，否则安装ext3grep的时可能会有问题。
[root@lunar tmp]# uname -a
Linux lunar 2.6.32-200.13.1.el5uek #1 SMP Wed Jul 27 21:02:33 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@lunar tmp]# rpm -qa |grep e2fs
e2fsprogs-libs-1.39-33.el5
e2fsprogs-1.39-33.el5
e2fsprogs-devel-1.39-33.el5
e2fsprogs-libs-1.39-33.el5
[root@lunar tmp]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
35G 3.3G 30G 10% /
/dev/sda1 99M 23M 71M 25% /boot
tmpfs 583M 0 583M 0% /dev/shm
/dev/sdb1 40G 4.3G 34G 12% /u01
/dev/sdc1 40G 1.9G 36G 5% /oradata
/dev/sdd1 40G 203M 38G 1% /other
[root@lunar tmp]#
如果你下载了rpm包，那么安装so easy:
[root@lunar tmp]# ls ext3grep-0.10.2-1.el5.rf.x86_64.rpm mapping-root scim-panel-socket:0-root spfile.bak [root@lunar tmp]# rpm -ivh ext3grep-0.10.2-1.el5.rf.x86_64.rpm warning: ext3grep-0.10.2-1.el5.rf.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 6b8d79e6 Preparing... ########################################### [100%] 1:ext3grep ########################################### [100%] [root@lunar tmp]# which ext3grep /usr/bin/ext3grep [root@lunar tmp]#
如果你下载了src的源码，那么可以如下方式安装：
[root@localhost src]# tar xfvz ext3grep-0.6.0.tar.gz [root@localhost ext3grep-0.6.0]# ./configure [root@localhost ext3grep-0.6.0]# make install [root@localhost ext3grep-0.6.0]# ext3grep Running ext3grep version 0.6.0
我们看下他的帮助，还是很强大的：
[root@lunar ~]# ext3grep
Running ext3grep version 0.10.2
No action specified; implying --superblock.
Usage: ext3grep [options] [--] device-file
Options:
--version, -[vV] Print version and exit successfully.
--help, Print this help and exit successfully.
--superblock Print contents of superblock in addition to the rest.
If no action is specified then this option is implied.
--print Print content of block or inode, if any.
--ls Print directories with only one line per entry.
This option is often needed to turn on filtering.
--accept filen Accept 'filen' as a legal filename. Can be used multi-
ple times. If you change any --accept you must remove
BOTH stage* files!
--accept-all Simply accept everything as filename.
--journal Show content of journal.
--show-path-inodes Show the inode of each directory component in paths.
Filters:
--group grp Only process group 'grp'.
--directory Only process directory inodes.
--after dtime Only entries deleted on or after 'dtime'.
--before dtime Only entries deleted before 'dtime'.
--deleted Only show/process deleted entries.
--allocated Only show/process allocated inodes/blocks.
--unallocated Only show/process unallocated inodes/blocks.
--reallocated Do not suppress entries with reallocated inodes.
Inodes are considered 'reallocated' if the entry
is deleted but the inode is allocated, but also when
the file type in the dir entry and the inode are
different.
--zeroed-inodes Do not suppress entries with zeroed inodes. Linked
entries are always shown, regardless of this option.
--depth depth Process directories recursively up till a depth
of 'depth'.
Actions:
--inode-to-block ino Print the block that contains inode 'ino'.
--inode ino Show info on inode 'ino'.
If --ls is used and the inode is a directory, then
the filters apply to the entries of the directory.
If you do not use --ls then --print is implied.
--block blk Show info on block 'blk'.
If --ls is used and the block is the first block
of a directory, then the filters apply to entries
of the directory.
If you do not use --ls then --print is implied.
--histogram=[atime|ctime|mtime|dtime|group]
Generate a histogram based on the given specs.
Using atime, ctime or mtime will change the
meaning of --after and --before to those times.
--journal-block jblk Show info on journal block 'jblk'.
--journal-transaction seq
Show info on transaction with sequence number 'seq'.
--dump-names Write the path of files to stdout.
This implies --ls but suppresses it's output.
--search-start str Find blocks that start with the fixed string 'str'.
--search str Find blocks that contain the fixed string 'str'.
--search-inode blk Find inodes that refer to block 'blk'.
--search-zeroed-inodes Return allocated inode table entries that are zeroed.
--inode-dirblock-table dir
Print a table for directory path 'dir' of directory
block numbers found and the inodes used for each file.
--show-journal-inodes ino
Show copies of inode 'ino' still in the journal.
--restore-inode ino[@seqnr][,ino[@seqnr],...]
Restore the file(s) with known inode number 'ino'.
The restored files are created in ./RESTORED_FILES/
with their inode number as extension (ie, inode.12345).
If '@seqnr' is provided then (only) the journal entry
with that sequence number is used, otherwise the latest
entry is used (if any). You can use that in the case a
a file was overwritten or truncated, rather than deleted.
--restore-file 'path' [--restore-file 'path' ...]
Will restore file 'path'. 'path' is relative to the
root of the partition and does not start with a '/' (it
must be one of the paths returned by --dump-names).
The restored directory, file or symbolic link is
created in the current directory as 'RESTORED_FILES/path'.
--restore-all As --restore-file but attempts to restore everything.
The use of --after is highly recommended because the
attempt to restore very old files will only result in
them being hard linked to a more recently deleted file
and as such polute the output.
--show-hardlinks Show all inodes that are shared by two or more files.
[root@lunar ~]#
[root@lunar ~]# ext3grep version
Running ext3grep version 0.10.2
No action specified; implying --superblock.
ext3grep: stat "version": No such file or directory
[root@lunar ~]#
模拟数据库文件被误删除，且数据库crash：
SYS% orcl> select name from v$datafile; NAME ----------------------------------------------------------- /oradata/orcl/system01.dbf /oradata/orcl/sysaux01.dbf /oradata/orcl/undotbs01.dbf /oradata/orcl/users01.dbf Elapsed: 00:00:00.01 SYS% orcl> [root@lunar oradata]# cd orcl [root@lunar orcl]# ll total 1758684 -rw-r----- 1 oracle oinstall 9912320 Aug 17 22:56 control01.ctl -rw-r----- 1 oracle oinstall 9912320 Aug 17 22:56 control02.ctl -rw-r----- 1 oracle oinstall 52429312 Aug 17 22:56 redo01.log -rw-r----- 1 oracle oinstall 52429312 Aug 17 22:39 redo02.log -rw-r----- 1 oracle oinstall 52429312 Aug 17 22:54 redo03.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo04.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo05.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo06.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo07.log -rw-r----- 1 oracle oinstall 576724992 Aug 17 22:54 sysaux01.dbf -rw-r----- 1 oracle oinstall 754982912 Aug 17 22:54 system01.dbf -rw-r----- 1 oracle oinstall 30416896 Aug 17 11:27 temp01.dbf -rw-r----- 1 oracle oinstall 73408512 Aug 17 22:54 undotbs01.dbf -rw-r----- 1 oracle oinstall 5251072 Aug 17 22:54 users01.dbf [root@lunar orcl]# rm -rf /oradata/orcl/users01.dbf [root@lunar orcl]# ls /oradata/orcl/users01.dbf ls: /oradata/orcl/users01.dbf: No such file or directory [root@lunar orcl]# SYS% orcl> alter system switch logfile; System altered. Elapsed: 00:00:00.08 SYS% orcl> SYS% orcl> shutdown abort ORACLE instance shut down. SYS% orcl> SYS% orcl> startup ORACLE instance started. Total System Global Area 626327552 bytes Fixed Size 2230952 bytes Variable Size 205522264 bytes Database Buffers 411041792 bytes Redo Buffers 7532544 bytes Database mounted. ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01110: data file 4: '/oradata/orcl/users01.dbf'
数据库启动报错，丢失了文件 ‘/oradata/orcl/users01.dbf’。
[root@lunar orcl]# ls /oradata/orcl/users01.dbf ls: /oradata/orcl/users01.dbf: No such file or directory [root@lunar orcl]#
现在使用ext3grep进行扫描和恢复：
ext3grep是针对ext3文件系统的（ext2单有自己的扫描恢复工具），确认丢失的文件是ext3文件体系:
[root@lunar ~]# cat /etc/fstab /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 /dev/sdb1 /u01 ext3 defaults 0 0 /dev/sdc1 /oradata ext3 defaults 0 0 /dev/sdd1 /other ext3 defaults 0 0 [root@lunar ~]# SYS% orcl> shutdown abort ORACLE instance shut down. SYS% orcl> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@lunar ~]$ ps -ef|grep dbw oracle 32639 32418 0 23:07 pts/1 00:00:00 grep dbw [oracle@lunar ~]$ ps -ef|grep ora_ oracle 32641 32418 0 23:07 pts/1 00:00:00 grep ora_ [oracle@lunar ~]$ ps -ef|grep pmon oracle 32643 32418 0 23:07 pts/1 00:00:00 grep pmon [oracle@lunar ~]$
这里，我的数据文件都在/oradata，是设备 /dev/sdc1 ：
[root@lunar orcl]# ext3grep /dev/sdc1 --ls --inode 2 （注意，必须使用inode 2，表示'..'，即，上一级目录)
Running ext3grep version 0.10.2
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: 320
Loading group metadata... done
Minimum / maximum journal block: 1545 / 35886
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1376706423 = Sat Aug 17 10:27:03 2013
Number of descriptors in journal: 13954; min / max sequence numbers: 3147 / 10086
Inode is Allocated
Finding all blocks that might be directories.
D: block containing directory start, d: block containing more directory entries.
Each plus represents a directory start that references the same inode as a directory start that we found previously.
Searching group 0: DDD
Searching group 1:
Searching group 2:
Searching group 3:
Searching group 4:
Searching group 5:
Searching group 6:
Searching group 7:
。。。。。。。。。。。。。。。。。。。。
Searching group 314:
Searching group 315:
Searching group 316:
Searching group 317:
Searching group 318:
Searching group 319:
Writing analysis so far to 'sdc1.ext3grep.stage1'. Delete that file if you want to do this stage again.
Result of stage one:
3 inodes are referenced by one or more directory blocks, 3 of those inodes are still allocated.
1 inodes are referenced by more than one directory block, 1 of those inodes is still allocated.
0 blocks contain an extended directory.
Result of stage two:
3 of those inodes could be resolved because they are still allocated.
All directory inodes are accounted for!
Writing analysis so far to 'sdc1.ext3grep.stage2'. Delete that file if you want to do this stage again.
The first block of the directory is 1539.
Inode 2 is directory "".
Directory block 1539:
.-- File type in dir_entry (r=regular file, d=directory, l=symlink)
| .-- D: Deleted ; R: Reallocated
Indx Next | Inode | Deletion time Mode File name
==========+==========+----------------data-from-inode------+-----------+=========
0 1 d 2 drwxrwxr-x .
1 2 d 2 drwxrwxr-x ..
2 3 d 11 drwxrwxr-x lost+found
3 end d 4358145 drwxr-x--- orcl
[root@lunar orcl]#
[root@lunar orcl]#
注意这里，我的数据库目录的inode是 4358145 ，下面我们开始从这个inode继续查找：
[root@lunar orcl]# ext3grep /dev/sdc1 --ls --inode 4358145
Running ext3grep version 0.10.2
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: 320
Minimum / maximum journal block: 1545 / 35886
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1376706423 = Sat Aug 17 10:27:03 2013
Number of descriptors in journal: 13960; min / max sequence numbers: 3147 / 10087
Inode is Allocated
Loading sdc1.ext3grep.stage2... done
The first block of the directory is 8742912.
Inode 4358145 is directory "orcl".
Directory block 8742912:
.-- File type in dir_entry (r=regular file, d=directory, l=symlink)
| .-- D: Deleted ; R: Reallocated
Indx Next | Inode | Deletion time Mode File name
==========+==========+----------------data-from-inode------+-----------+=========
0 1 d 4358145 drwxr-x--- .
1 2 d 2 drwxrwxr-x ..
2 3 r 4358146 rrw-r----- system01.dbf
3 4 r 4358147 rrw-r----- sysaux01.dbf
4 6 r 4358148 rrw-r----- undotbs01.dbf
6 7 r 4358150 rrw-r----- control01.ctl
7 8 r 4358151 rrw-r----- control02.ctl
8 9 r 4358152 rrw-r----- redo01.log
9 10 r 4358153 rrw-r----- redo02.log
10 11 r 4358154 rrw-r----- redo03.log
11 12 r 4358155 rrw-r----- temp01.dbf
12 13 r 4358156 rrw-r----- sby_redo04.log
13 14 r 4358157 rrw-r----- sby_redo05.log
14 15 r 4358158 rrw-r----- sby_redo06.log
15 16 r 4358159 rrw-r----- sby_redo07.log
16 17 r 4358149 rrw-r--r-- sdc1.ext3grep.stage1
17 end r 4358160 rrw-r--r-- sdc1.ext3grep.stage2 这里可以看到，users01.dbf
[root@lunar orcl]#
文件的inode已经被覆盖了
这里根据两个两个信息进行恢复文件的操作：
（1）数据库报错告诉我们需要恢复的文件名称：/oradata/orcl/users01.dbf
（2）ext3grep的提示信息告诉我们了从哪里开始写文件： Inode 4358145 is directory “orcl”.
恢复过程如下：
[root@lunar orcl]# ext3grep /dev/sdc1 --restore-file orcl/users01.dbf Running ext3grep version 0.10.2 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: 320 Minimum / maximum journal block: 1545 / 35886 Loading journal descriptors... sorting... done The oldest inode block that is still in the journal, appears to be from 1376706423 = Sat Aug 17 10:27:03 2013 Number of descriptors in journal: 13962; min / max sequence numbers: 3147 / 10088 Writing output to directory RESTORED_FILES/ Loading sdc1.ext3grep.stage2... done Cannot find an inode number for file "orcl/users01.dbf". 注意这里，比如是 orcl开始的，表示从这个inode开始的，不能写成"/oradata/orcl/users01.dbf或者“/orcl/users01.dbf” [root@lunar orcl]#
从上面提示我们看到了文件已经恢复出来了，放在 orcl/RESTORED_FILES 下面：
[root@lunar RESTORED_FILES]# pwd /oradata/orcl/RESTORED_FILES [root@lunar RESTORED_FILES]# ls -lrt total 0 [root@lunar RESTORED_FILES]# cd .. [root@lunar orcl]# ls -lrt total 1753556 -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo07.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo06.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo05.log -rw-r----- 1 oracle oinstall 52429312 Apr 4 19:56 sby_redo04.log -rw-r----- 1 oracle oinstall 30416896 Aug 17 11:27 temp01.dbf -rw-r----- 1 oracle oinstall 52429312 Aug 17 22:54 redo03.log -rw-r----- 1 oracle oinstall 52429312 Aug 17 22:57 redo02.log -rw-r----- 1 oracle oinstall 52429312 Aug 17 22:57 redo01.log -rw-r----- 1 oracle oinstall 73408512 Aug 17 23:05 undotbs01.dbf -rw-r----- 1 oracle oinstall 754982912 Aug 17 23:05 system01.dbf -rw-r----- 1 oracle oinstall 576724992 Aug 17 23:05 sysaux01.dbf -rw-r----- 1 oracle oinstall 9912320 Aug 17 23:06 control02.ctl -rw-r----- 1 oracle oinstall 9912320 Aug 17 23:06 control01.ctl -rw-r--r-- 1 root root 203 Aug 17 23:10 sdc1.ext3grep.stage1 -rw-r--r-- 1 root root 157 Aug 17 23:10 sdc1.ext3grep.stage2 drwxr-xr-x 2 root root 4096 Aug 17 23:30 RESTORED_FILES [root@lunar orcl]# [root@lunar orcl]#
完了不行了，被覆盖了。。。否则这一步就会在当前执行ext3grep的目录下找到一个RESTORED_FILES目录，里面就是我们的user01.dbf文件，再之后，你懂的。。
把他copy到/oradata/orcl/users01.dbf，然后执行recover datafile ‘/oradata/orcl/users01.dbf’，在open，就ok了。。。
我们再测试另一个工具extundelete（感觉原理跟ext3grep一样），看看他是不是强大一些，o(∩_∩)o 哈哈：
[root@lunar tmp]# bunzip2 extundelete-0.2.4.tar.bz2 [root@lunar tmp]# ls ext3grep-0.10.2-1.el5.rf.x86_64.rpm extundelete-0.2.4.tar mapping-root scim-panel-socket:0-root spfile.bak [root@lunar tmp]# tar xvf extundelete-0.2.4.tar extundelete-0.2.4/ extundelete-0.2.4/acinclude.m4 extundelete-0.2.4/missing extundelete-0.2.4/autogen.sh extundelete-0.2.4/aclocal.m4 extundelete-0.2.4/configure extundelete-0.2.4/LICENSE extundelete-0.2.4/README extundelete-0.2.4/install-sh extundelete-0.2.4/config.h.in extundelete-0.2.4/src/ extundelete-0.2.4/src/extundelete.cc extundelete-0.2.4/src/block.h extundelete-0.2.4/src/kernel-jbd.h extundelete-0.2.4/src/insertionops.cc extundelete-0.2.4/src/block.c extundelete-0.2.4/src/cli.cc extundelete-0.2.4/src/extundelete-priv.h extundelete-0.2.4/src/extundelete.h extundelete-0.2.4/src/jfs_compat.h extundelete-0.2.4/src/Makefile.in extundelete-0.2.4/src/Makefile.am extundelete-0.2.4/configure.ac extundelete-0.2.4/depcomp extundelete-0.2.4/Makefile.in extundelete-0.2.4/Makefile.am [root@lunar tmp]# ls ext3grep-0.10.2-1.el5.rf.x86_64.rpm extundelete-0.2.4.tar scim-panel-socket:0-root extundelete-0.2.4 mapping-root spfile.bak [root@lunar tmp]# cd extundelete-0.2.4 [root@lunar extundelete-0.2.4]# ls acinclude.m4 autogen.sh configure depcomp LICENSE Makefile.in README aclocal.m4 config.h.in configure.ac install-sh Makefile.am missing src [root@lunar extundelete-0.2.4]# ./configure Configuring extundelete 0.2.4 Writing generated files to disk [root@lunar extundelete-0.2.4]# [root@lunar extundelete-0.2.4]# extundelete /dev/sdc1 --restore-file /oradata/orcl/user01.dbf WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set. The partition should be unmounted to undelete any files without further data loss. If the partition is not currently mounted, this message indicates it was improperly unmounted, and you should run fsck before continuing. If you decide to continue, extundelete may overwrite some of the deleted files and make recovering those files impossible. You should unmount the file system and check it with fsck before using extundelete. Would you like to continue? (y/n) y Loading filesystem metadata ... 320 groups loaded. Loading journal descriptors ... 14916 descriptors loaded. Failed to restore file /oradata/orcl/user01.dbf Could not find correct inode number past inode 2. Try altering the filename to one of the entries listed below. File name | Inode number | Deleted status . 2 .. 2 lost+found 11 orcl 4358145 extundelete: Operation not permitted while restoring file. extundelete: Operation not permitted when trying to examine filesystem [root@lunar extundelete-0.2.4]# [root@lunar extundelete-0.2.4]#
单独恢复文件也没戏。。。。
结论：
经过测试，如果使用恢复全部命令，很多时候可以抢救更多数据，因为extundelete有可能会把恢复的文件改名，并放到其它目录中。
而且，遇到上面的错误后，也可以使用all来试试运气，例如：
[root@lunar /]# extundelete /dev/sdb1 --restore-directory /stage/lunar Loading filesystem metadata ... 28 groups loaded. Loading journal descriptors ... 11376 descriptors loaded. Failed to restore file /stage/lunar Could not find correct inode number past inode 2. Try altering the filename to one of the entries listed below. File name | Inode number | Deleted status . 2 .. 2 travel 32705 Deleted backup 327041 bbed 408801 Deleted dul 179873 Deleted odu 147169 Deleted ff 425153 Deleted lunar 32705 roger 245281 Deleted fast_recovery_area 261633 lost+found 11 extundelete: Operation not permitted while restoring directory. extundelete: Operation not permitted when trying to examine filesystem [root@lunar /]# [root@lunar /]# extundelete /dev/sdb1 --restore-all Loading filesystem metadata ... 28 groups loaded. Loading journal descriptors ... 11376 descriptors loaded. Searching for recoverable inodes in directory / ... 23 recoverable inodes found. Looking through the directory structure for deleted files ... Unable to restore inode 261634 (fast_recovery_area/TRAVEL): Space has been reallocated. Block 532480 is allocated. Unable to restore inode 261646 (fast_recovery_area/LUNAR/archivelog/2015_01_13/o1_mf_1_94_bbp9r02b_.arc): Space has been reallocated. Unable to restore inode 261647 (fast_recovery_area/LUNAR/archivelog/2015_01_13/o1_mf_1_95_bbp9xtxs_.arc): Space has been reallocated. Unable to restore inode 261648 (fast_recovery_area/LUNAR/archivelog/2015_01_13/o1_mf_1_96_bbp9ydr0_.arc): Space has been reallocated. Unable to restore inode 261649 (fast_recovery_area/LUNAR/archivelog/2015_01_13/o1_mf_1_97_bbp9z68q_.arc): Space has been reallocated. 9 recoverable inodes still lost. Block 325403 is allocated. Unable to restore inode 261635 (file.261635): Space has been reallocated. Unable to restore inode 261636 (file.261636): Space has been reallocated. Unable to restore inode 261637 (file.261637): Space has been reallocated. Block 533126 is allocated. Unable to restore inode 261640 (file.261640): Space has been reallocated. Unable to restore inode 261641 (file.261641): Space has been reallocated. [root@lunar /]# [root@lunar /]# ls bin dev home lib lost+found misc opt proc root selinux stage tftpboot u01 var boot etc kfed lib64 media mnt other RECOVERED_FILES sbin srv sys tmp usr [root@lunar /]# mv RECOVERED_FILES/ /other [root@lunar /]# [root@lunar other]# ls lost+found RECOVERED_FILES undelete [root@lunar other]# cd RECOVERED_FILES/ [root@lunar RECOVERED_FILES]# ls fast_recovery_area file.261638 file.261639 file.32716 [root@lunar RECOVERED_FILES]# ll total 139896 drwxr-xr-x 3 root root 4096 Jan 13 08:43 fast_recovery_area -rw-r--r-- 1 root root 46579712 Jan 13 08:50 file.261638 -rw-r--r-- 1 root root 46578688 Jan 13 08:50 file.261639 -rw-r--r-- 1 root root 104865792 Jan 13 08:50 file.32716 drwxr-xr-x 2 root root 4096 Jan 13 08:50 lunar [root@lunar RECOVERED_FILES]# [root@lunar lunar]# ll total 3024 -rw-r--r-- 1 root root 31465472 Jan 13 08:43 temp01.dbf -rw-r--r-- 1 root root 31465472 Jan 13 08:50 temp01.dbf.v1 [root@lunar lunar]#
看，我这里已经通过恢复全部命令的方式找到了删除的temp01.dbf。
