Ubuntu restores deleted files
Accidentally yesterday, performed the RM xx-rf and removed a project. Then there are all kinds of remorse, all kinds of remorse, this project is a week's workload ah. Finally must solve, so Google search found the recovery artifact Extundelete, and finally successfully recovered all the deleted by my unintentional files. Thank God, thank Extundelete. The following is a summary of personal experience. How to use Extundelete
1) Download Tool Extundelete
Ubuntu Download this tool is too easy [Python] view plain copy sudo apt-get install Extundelete
2) Use
This is also very easy to use. Using the Extundelete–help command, you can tell us a lot.
[Python] View Plain Copy itleaks@ itleaks::~$ extundelete --help usage: extundelete [ options] [--] device-file options: ................... --after dtime only process entries deleted on or after ' Dtime ' . --before dtime Only process entries deleted before ' Dtime ' . actions: ............ --restore-file ' path ' Will restore file ' path ' . ' path ' is relative to root of the partition and does not start with a '/' (it must be one of the paths returned by --dump-names) . The restored file is created in the current directory as ' Recovered_files/path ' . -- restore-files ' path ' will restore files which are listed in the file ' path ' . each filename should be in the same format as an option to -- restore-file, and there should be one per line. -- output-dir ' path ' Restore files in the output dir ' Path ' . by default the restored files are created under current directory ' Recovered_files ' . - -restore-all attempts to restore Everything. &nBsp ...........
We know that when we accidentally delete useful files, we are generally more likely to know the time of deletion, so the use of time this option can quickly and accurately restore the files we want. How is this dtime generated? Please refer to the following command:
[python] view plain copy itleaks@ itleaks:~$ date-d "2014-06-01 23:02:00" +%s 1401634920
%s means seconds since 1970-01-01 00:00:00 UTC, which is the time difference between entering and 1970-01-0100:00:00
You can then use this to restore the [python] view plain copy sudo extundelete/dev/sda8--after 1401634920--restore-all
Now let's do a trial: The following are the details
[Python] View plain copy itleaks@ itleaks:/tmp$ echo "Recovery test" > itleaks.test itleaks@ itleaks:/tmp$ rm itleaks.test itleaks@ itleaks:/tmp$ date -d "2014-06-01 22:28:00" +%s 1401632880 itleaks@ itleaks:/tmp$ sudo extundelete /dev/sda8 --after 1401632880 --restore-all only show and process deleted entries if they are deleted on or after 1401632880 and before 9223372036854775807. warning: extended attributes are not restored. 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 ... 378 groups loaded. loading journal descriptors ... 27106 descriptors loaded. Searching for recoverable inodes in directory / ... 85 recoverable inodes found. Looking through the directory structure for deleted files ... .................... unable to restore inode 2360218 (etc/brltty/ Brl-fs-bumpers.kti): no undeleted copies found in the journal. unable to restore inode 2359564 (etc/mtab~): no undeleted copies found in the journal. restored inode 2883641 to file recovered_files/tmp/itleaks.test Itleaks@ itleaks:/tmp$ tree recovered_ files/ recovered_files/ └── tmp └── itleaks.test 1 directory, 1 file extundelete principle
This is due to the organizational structure of the Linuxext3 file system, as shown in the following figure:
In Linux, the Super Block describes the information of the partition, a partition is divided into two parts, the Index node table and the data block area, which is set up in the format. File (directory is also a file, but its content is described in the directory of files) by the index node description, the index node describes the file modification time, file name, file block address and so on. Also, Linux is a lazy action for file deletion operations, when you delete a file, the system simply makes the index node of the file and its own block of data available to free (will nlink=0), and does not do any other empty, only when the index node or block is actually used to modify the data inside. This provides us with the opportunity to file repair. Because of the fixed size of the index nodes in the system, it is easy to traverse all the index nodes in the scanning system, find the index nodes of free and check whether the blocks have been used, and if they are not, they can be repaired and repaired. At the same time, because the information in the index node is also reserved, the specific deleted files can be recovered according to the time. Considerations After a file is mistakenly deleted
From the analysis above, we can know that, after the deletion of files, try not to do large data operations, so as to avoid the deleted files of the data block is reused, resulting in complete loss of data.
/********************************
* This article from the blog "Love Kicking Door"
* Reprint Please indicate the source: Http://blog.csdn.net/itleaks
******************************************/