The Windows platform recovers deleted data so easily, but Linux is not that simple because there is no recycle Bin. But, if one day really accidentally deleted the file, then how is good? Then extundelete with the restoration artifact.
The following are my virtual machine operation, tested, file system EXT3/EXT4 are applicable.
First, install the Extundelete
1, need to install the dependency package, otherwise the compilation does not pass
[[email protected]/] #yum install e2fsprogs*-y
2. Download and install Extundelete
: Https://sourceforge.net/projects/extundelete/files/latest/download
[[email protected]/] #tar-jxvf extundelete-0.2.4.tar.bz2 [[email protected]/] #cd Extundelete-0.2.4[[email protected]/ ]#./configure--prefix=/usr/local/extundelete[[email protected]/] #make && make install
3, configure the temporary environment variables, if the permanent write to the profile
[[email protected]/] #PATH = $PATH:/usr/local/extundelete/bin
4. Verify that the installation is successful
[Email protected]/]# extundelete-vextundelete version 0.2.4libext2fs version 1.41.12Processor is little endian.
Second, recover deleted data
For ease of testing, a separate partition/DEV/SDB1 is created, mounted/reed
[[email protected]/] #mount/dev/sdb1/reed
1. Create a test file
[[email protected]/]# Cd/reed/[[email protected] reed]# CP ~/extundelete-0.2.4.tar.bz2. [[email protected] reed]# echo "Reed" >>del.file[[email protected] reed]# lltotal 132-rw-r--r--1 root root 5 Ma R 07:20 del.file-rw-r--r--1 root root 108472 Mar 07:20 extundelete-0.2.4.tar.bz2drwx------2 root root 16384 Mar 1 6 06:45 Lost+found
2. Delete Files
[[Email protected] reed]# RM *rm:remove regular file ' Del.file '? Yrm:remove regular file ' extundelete-0.2.4.tar.bz2 '? Yrm:cannot remove ' lost+found ': is a directory[[email protected] reed]# lltotal 16drwx------2 root root 16384 Mar 16 06: Lost+found
3. View the Inode value of the/reed
[Email protected] reed]# Ls-id/reed2/reed
4. Uninstalling the/reed partition
[Email protected] reed]# CD. [Email protected]/]# Umount/reed
5. Recover deleted data
Note: The default deleted file will revert to the Recovered_files directory in the current directory
5.1 View deleted files first
[[email protected] /]# extundelete /dev/sdb1 --inode=2notice: extended Attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Group: 0contents of inode 2:0000 | ed 41 00 00 00 10 00 00 ec 98 e8 56 e9 98 e8 56 | . A......... V... v0010 | e9 98 e8 56 00 00 00 00 00 00 03 00  08 00 00 00 |&NBSP, ..... V............ 0020 | 00 00 00 00 00 00 00 00 41 02 00 00  00 00 00 00 |&NBSP, ... A....... 0030 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 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 |&NBSP, .......... 0060 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 0070 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 0080 | 1c 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 0090 | 6e 90 e8 56 00 00 00 00 00 00 00 00 00 00 00 00 | n. V............ 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 |&NBSP, .......... 00c0 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 00d0 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 00e0 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... 00f0 | 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 00 |&NBSP, .......... inode is allocatedfile mode: 16877low 16 bits of owner uid: 0size in bytes: 4096access time: 1458084076creation time: 1458084073modification time: 1458084073deletion time: 0low 16 bits of group id: 0links count: 3Blocks count: 8File flags: 0File version (FOR NFS): 0file Acl: 0directory acl: 0fragment address: 0direct blocks: 577, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0indirect block: 0double indirect block: 0Triple indirect block: 0File name | Inode number | deleted status. 2.. 2lost+found 11extundelete-0.2.4.tar.bz2 12 deleteddel.file 13 deleted
Files marked "Deleted" are files that have been deleted
5.2 Recovery
[[email protected] /]# extundelete --restore-all /dev/sdb1notice: extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Loading journal descriptors ... 23 descriptors loaded. Searching for recoverable inodes in directory / ... 2 recoverable inodes found. Looking through the directory structure for deleted files ... 0 recoverable inodes still lost. [[email protected] /]# ll recovered_files/total 112-rw-r--r-- 1 root Root 5 mar 16 07:25 del.file-rw-r--r-- 1 root  ROOT 108472 MAR 16 07:25 EXTUNDELETE-0.2.4.TAR.BZ2
5.3 Accomplished.
There are, of course, many other parameters, such as the ability to specify a file to restore a point in time.
Third, the extension of knowledge: The Linux system rm Delete file principle
Transferred from: http://blog.csdn.net/grantlee1988/article/details/8057228
Most of the time, we will find that a process is reading and writing to the current file, but we still can RM, is it strange? And under Windows, there will be an error, "The current file is being used", which has to be removed from the Linux under the principle of the file.
Linux is controlled by the number of link to delete the file, only if a file does not exist any link, the file will be deleted. In general, there are 2 link counters for each file: I_count and I_nlink.
The meaning of I_count is the number of users (or calls) of the current file, i_nlink the amount of media connections (number of hard links), which can be understood as I_count is the memory reference counter, and I_nlink is the reference counter for the disk.
When a file is referenced by a process, the corresponding number of i_count is incremented, and the corresponding I_nlink number is incremented when a hard link to the file is created.
For the Delete command RM, the actual reduction is the disk reference count I_nlink. There is a problem here, if a file is being called by a process and the user is performing an RM operation to delete the file, what will happen? When the user performs an RM operation to delete a file and then executes the LS or other file management commands, the file can no longer be found, but the process of invoking the deleted file continues to execute normally and the content can be read and written correctly from the file. Why is that?
This is because the RM operation only reduces the file I_nlink, if there is no other link i_nlink is 0, but because the file is still referenced by the process, so the file corresponding to the I_count is not 0, so even if the RM operation, but the system does not really delete the file, When only I_nlink and I_count are 0, the file is actually deleted. That is, you also need to dismiss the process's call to the file.
The above-mentioned I_nlink and I_count is the true condition of the file deletion, but when the file is not called, does the RM operation delete the file after the deletion can be retrieved?
Said before, RM Operation just reduce the file I_nlink, or 0, the actual is the file name to the Inode link deleted, at this time, and not delete the file entity (Block data block), at this time, if the machine to stop work, the data can be retrieved, If you continue to write data at this point, when the new data is likely to be allocated to the block blocks of data being deleted, the file is actually recycled.
Note: According to the above principle, the actual situation will be the following problems, the Web server disk space is not enough, delete all the useless log or first disk space is not enough, but with du-sh/* found disk space is much smaller than the total size of the hard disk, this is because only a i_nlink is deleted, There are other processes that use these log files, Apache or Tomcat, and reboot and look OK.
This article is from "[[email protected] Prof. Open ~] #rm-rf/" blog, please be sure to keep this source http://luweikai.blog.51cto.com/1705672/1751688
Use Extundelete to recover EXT3/EXT4 partition data under Linux