Just recently (yesterday, in fact), I made the stupid mistake of deleting some rather important project files. It wouldn’t have been too bad had these files been in Subversion. However, they weren’t. As such, I didn’t find the prospect of spending an additional 3 weeks’ development rewriting the lost code.
So, I began searching for some sort of file recovery utility for the EXT4 partition type with journaling. Initially, the results didn’t seem too positive. Most of the responses were suggesting that I’d basically need to perform a sudo strings /dev/sdaX > /home/geoff/dataPartition.txt in order to get all the string data on the partition into a file, and parse through the file from there, extracting out the data I need.
That sounded like a lot of work. Considering I had just deleted the files, I figured there had to be something better. Eventually, I found a ridiculously useful (and awesome) file recovery application, named extundelete. It’s an open source project that is available from SourceForge. You can view the project’s homepage at extundelete.sourceforge.net.
What follows is an account of the processes I followed in using extundelete to recover my deleted files. Please note that I am merely providing this account in the hope that it might help someone else. I cannot take responsibility for any damage caused by replicating this process on your own computer.
1. Make sure no more data can be lost
Before making any changes, if the files you’re trying to restore are residing on a separate partition, you’ll probably want to remount that partition as read-only, to prevent any accidental over-writing. You can do this using the following command (assuming there are no processes accessing files on it, and you’ve replaced “X” with the corresponding partition number):
$ sudo mount -o remount,ro /dev/sdaX
2. Download and extract the source files
Next, you will need to visit the extundelete project page on Sourceforge, and download the source files. After downloading, extract the source files to a location of your choosing, on a partition that is writable. If you’re happy to do this to the directory into which the archive was downloaded, it is a simple case of executing this command:
$ tar -xvvf downloaded-filename.tar.gz
3. Install additional dependencies
Before I was able to run the compilation process successfully, I found that I was required to install some additional dependencies. If you too haven’t built from source before, you will probably need to do the same. The below are the commands I performed in order to successfully build from source:
$ sudo apt-get install build-essential $ sudo apt-get install ext2fs-dev
4. Compile the source
Once the dependencies have been installed successfully, issue the following commands from the application’s source file folder to build the application:
$ ./configure $ make
If you want to “install” it, so that it is available from your /usr/local/bin/ directory, you can issue the following command:
$ sudo make install
5. Begin file recovery
Once you have finished compiling the application, change to the src/ directory within the source file directory. The compiled application should be residing there, in a file called extundelete. Executing ./extundelete -h will provide you with a list of options available to be used with the application. I found that the following invocation worked for me:
$ sudo ./extundelete /dev/sdaX --restore-all --after 1291845600
There is apparently an option that can be specified which will change the save directory of the recovered files which is used by adding --restore-directory /home/username/recovered_files/. However, I only read about this on another blog, and couldn’t find it in the extundelete help contents. Attempting to add it to my command line invocation didn’t seem to work either.
This means that all recovered files will be saved to src/RECOVERED_FILES/. Considering the recovery was performed as root, you’ll find that the recovered files will be owned by root. you won’t be able to modify the files, even though you will be able to access them.
Once extundelete has completed running, you should find the recovered files available for you to copy and paste as you see fit. I found that extundelete managed to recover almost all of my deleted files. There were some files that needed to be downloaded and copied in again, but on the whole, the bulk of the lost files were recovered successfully. So what could have been days worth of work in recovering the files, turned out to only be about 2 – 3 hours worth of work in recovering weeks worth of work.
Not bad, methinks. I hope you’ve found this helpful. If you have, I’d really like to know about it.
If you need any specific help, hit me up in the comments, and I’ll try to help you out where possible.
Comments
extundelete restore-directory /dev/sda7/data/2011
I get this:
No action specified; implying --superblock.
I am not using sudo.
Any ideas what I'm doing wrong?
I have a thread here that explains a bit more detail.
http://forums.debian.net/viewtopic.php?f=10&t=59302
Thanks
I see on the link to the Debian forum you supplied that you've since managed to recover some of the data, which is awesome.
But, from what I can see, in the command line code you supplied, you weren't providing an action for extundelete to execute. It should have been "--restore-directory" instead of "restore-directory".
Additionally, I'm not certain that "--restore-directory" is actually even a parameter. I have noticed that the documentation is a little bit out of sync compared with what is displayed with you run "extundelete --help".
[code]mike@vaio ~ $ sudo extundelete /dev/sda7 --restore-directory data/2010
WARNING: Extended attributes are not restored.
Loading filesystem metadata ... 2270 groups loaded.
Loading journal descriptors ... 30118 descriptors loaded.
Searching for recoverable inodes in directory data/2010 ...
18549 recoverable inodes found.
Looking through the directory structure for deleted files ...
Failed to restore inode 10093033 to file RECOVERED_FILES/data/2010/london-2010:Inode does not correspond to a regular file.
Restored inode 10104871 to file RECOVERED_FILES/data/2010/london-2010/PICT0485.JPG
Restored inode 10104872 to file RECOVERED_FILES/data/2010/london-2010/PICT0487.JPG
Restored inode 10104873 to file RECOVERED_FILES/data/2010/london-2010/PICT0488.JPG
Restored inode 10104874 to file RECOVERED_FILES/data/2010/london-2010/PICT0484.JPG
Restored inode 10104875 to file RECOVERED_FILES/data/2010/london-2010/PICT0486.JPG
Restored inode 10104181 to file RECOVERED_FILES/data/2010/Thumbs.db
Restored inode 10104182 to file RECOVERED_FILES/data/2010/.directory
Restored inode 10104183 to file RECOVERED_FILES/data/2010/me in Croatia.jpg
18540 recoverable inodes still lost.
mike@vaio ~ $
[/code]
the lost but recoverable inodes sounds worrying but intruiging. I am hoping that there will be some way of unlosing them!
...
The restored file is created in the current directory as 'RECOVERED_FILES/path'.
...
so first "cd /path/to/recovered/files/
;-)
109 recoverable inodes found.
Looking through the directory structure for deleted files ...
109 recoverable inodes still lost.
No files were undeleted.
any help on getting through this problem?
Jade