A Real File Recovery Scenario On Ext4 Filesystem

I just pressed the Enter key on the file delete confirmation dialog, and removed my code which I was working on for 3 hours. In fact I had made such a mistake before and had no results searching “Ext3 Recovery / Ext4 Recovery …”. But this time, a new project named extundelete appeared which claims to extract file metadata from the file-system’s Journal.

I tried to extract and compile it by just typing “make” and found that ext2fs library is missing, so I installed ext2fs-dev package using the following command (I’m using Ubuntu 9.10) :

sudo apt-get install ext2fs-dev

Then typing “make” in the src folder, presents you the binary file named “extundelete”. You can run it like this :

ali@Velocity:~/tmp/extundelete-0.1.8/src$ ./extundelete
No action specified; implying --superblock.

Usage: ./extundelete [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.
--journal              Show content of journal.
--after dtime          Only process entries deleted on or after 'dtime'.
--before dtime         Only process entries deleted before 'dtime'.

Actions:
--inode ino            Show info on inode 'ino'.
--block blk            Show info on block 'blk'.

--restore-inode ino     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).

--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.

--restore-all          Attempts to restore everything.
-j journal             Reads an external journal from the named file.
-b blocknumber         Uses the backup superblock at blocknumber when
                                opening the file system.
-B blocksize           Uses blocksize as the block size when opening fs.
                       The number should be the number of bytes.

It seems that running the program with –restore-all, should restore all possible files. Like this :

ali@Velocity$ ./extundelete /dev/sda6 --restore-all

But that option gave me some temporary, hidden and some useless config files over my home folder. I was thinking of rewriting the code …

Suddenly I found that, extundelete supports another option in which you can specify the inode number of your file, and it will bring it back … 🙂

Looking at manual of the “ls” command you’ll find that running “ls” with -i parameter will give you the inode number of files in a directory. I tried to find a range for inode files around the deleted file and search for all files in the range …

ali@Velocity:~/projects/Monko-MovieQuiz/Source/IMDBot/src$ ls -i
7824227 artists.db
7824222 google_spell_checker.py
7824220 merge_tool.py
7824214 movies-merged.db
7824219 movies-vahid.db
7824260 stuff.py
7824252 artists.py
7824211 IMDB.py
7824221 MovieDatabase.py
7824254 movies-sohrab.db
7824256 question_validator.py
7864492 tests
7864514 cache
7824305 lite_tool.py
7824208 MovieDatabase.pyc
7824207 movies-soroush.db
7824293 start.py
7962711 Tools

It seems that most of the files are in the range of 7824xxx, so searching the range of to 7824000 to 7824999 might be a good idea (take a look at the following bash code snippet) :

for((i=7824000; i<7824999; i++)); do
./extundelete /dev/sda6 --restore-inode $i ;
done

Viva !

I got 7 deleted files in this range (inside the RECOVERED_FILES directory), and one of them was my deleted python code ! And I spent my time on writing this article instead of rewriting the code 😉