Geoffrey Garbers Thoughts on everything from PHP to photography

Recovering recently deleted files from an EXT3/EXT4 (with journaling) partition

Posted 7 months from now.

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

mike 4 months ago
Hi Geoff, my data partition had all my data in a directory /data. It got replaced by accident by an empty directory called /data. (dont know how, something to do with me copying it's own sysmlink back to it accidently, - it should not have happened and it's a long story!) Gparted sees it as /dev/sda7. I'm trying to recover some smaller directories as I dont have enough room to restore the whole partition, but I am having problems getting the path correct, or something. It should work with the partition unmounted trying this:

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
Geoff Garbers 4 months ago
Hey Mike.

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".
Mike 4 months ago
Hi Geoff, I got a little help from corenominal over at crunchbang on getting the args right. --restore-directory must be a recent addition, and date format seems to have changed too. I have retrieved a few important files, but I am getting a lot of errors too. I dont have space to try restoring the partition. Will be buying another usb drive and installing crunchbang on it so there is plenty of room for the data that can be retrieved without filling my working partition to full capacity. This is the sort of thing I am getting:
[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!
Phil 3 months from now
$ extundelete -h

...
The restored file is created in the current directory as 'RECOVERED_FILES/path'.
...

so first "cd /path/to/recovered/files/

;-)
André Garcia 6 months from now
It worked perfectly! Thank you Geoff!
Geoff Garbers 7 months from now
Glad to know it helped someone else :)
Jade 4 months ago
We have recently lost a large amount of files by accidentally delete a folder in the ext3. We have installed the extundelete program and follow the steps and at the end get this report:

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
Geoff Garbers 4 months ago
Hey Jade. I can try help. Could you paste what it is you're invoking from the command line?

Leave a reply

Your email address will not be published. Required fields are marked *

*