↓Skip to main content

Recovering deleted files from Linux ext3 filesystem on Cloud Servers

·6 mins

Every now and then you hit enter on your keyboard and next second you realize your mistake, you just deleted some files by mistake. Immediately your mind starts thinking about your backups, changes you have made since last available backup, and all that..

Well, today I faced the challenge of recovering some accidentally deleted from from one of my cloud servers. As we all know data never actually gets deleted from the hard disk, it gets unlinked from the file system table and then those blocks get overwritten by other data. So, as soon as I realized that I have accidentally deleted the files, I booted the Cloud Server into rescue mode. I did this because then my original HDD of the cloud server is not mounted RW and is not in use. Then I downloaded my good old friend TestDisk, downloaded it and compiled, but bummer, it doesn’t recognize the HDD in cloud servers, don’t ask me why but it doesn’t may be it doesn’t have drivers for handling virtual hdds. So, what next??

With some googling I found this link http://carlo17.home.xs4all.nl/howto/undelete_ext3.html. I really recommend that you give it a good read, very well explained by the developer how the program actually works. The Developer of the ext3grep program wrote it to recover his own deleted files, as per his words “don’t expect it to work out-of-box”, and

Anyway, back to topic, I downloaded the code from http://code.google.com/p/ext3grep/ There were few other obstacles in the normal compiling and using it and finally recovering the deleted files. So, I’ll explain the steps and additional packages you will need to compile the ext3 and running it successfully.

Download the latest ext3grep code:

# wget http://ext3grep.googlecode.com/files/ext3grep-0.10.2.tar.gz

Extract the contents of the tar.gz file

# tar -xzf ext3grep-0.10.2.tar.gz

Install the following dependency packages, these are needed for compiling the ext3grep code.

# yum install gcc cpp
# yum install gcc-c++ libstdc++
# yum install e2fsprogs-devel

Now go into the extracted ext3grep directory and run the following commands:

# cd ext3grep-0.10.2
# ./configure

./configure command should finish without any errors with the following lines in the bottom of the output.

[...]
configure: creating ./config.status
config.status: creating src/timestamp-sys.h
config.status: sys.h is unchanged
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands

If the ./configure command runs without any errors, that means all the required dependencies are met. But even if it shows some problem, then just look at the error and improvise yourself. Just check what it’s looking for and install those dependencies.

Next, please run the following commands

# make
# make install

This will compile the ext3grep program, which you can use to recover the files.

Now, let’s talk about few things you need to know before starting to use the program. I have read through the long article and will try to spit out few main points about the program.

The program assumes a spike of recently deleted files (shortly before the last unmount). It does NOT deal with a corrupted file system, only with accidentally deleted files.

Also, the program is beta: the development of the program was done as a hack, solely aimed at recovering developer’s own data. He fixed few of the bugs that didn’t show in his case, but over all the program isn’t as robust as it could be. Therefore, it is likely that things might not work entirely out-of-the-box for you. The program is stashed with asserts, which makes it likely that if something doesn’t work for you then the program will abort instead of trying to gracefully recover. In that case you will have to dig deeper, and finish the program yourself, so to say.

The program only needs read access to the file system with the deleted files: it does not attempt to recover the files. Instead, it allows you to make a copy of deleted files and writes those to a newly created directory tree in the current directory (which obviously should be a different file system). All paths are relative to the root of the partion, thus— if you are analyzing a partition /dev/md5 which was mounted under /home, then /home is unknown to the partition and to the program and therefore not part of the path(s). Instead, a path will be something like for example “carlo/c++/foo.cc”, without leading slash. The partition root (/home in the example) is the empty string, not ‘/’.

Just one more thing before you attempt to recover your files, the ext3grep program expects to find lost+found directory in the file system, and since our /dev/sda1 is not mounted in the rescue mode, there is no lost+found directory, the workaround is to mount the /dev/sda1 and just create a new directory inside it named lost+found, and unmount it.

Now for recovering files, ext3grep provides many command line options, it allows you to look for the superblock and read the superblock information. It can show you which inode resides in which block group. It can even prints the whole contents of a single inode, like all blocks linked to that inode and other data about the inode. You can read more in the original article of ext3grep as mentioned in the starting of the article.

Enough about theory, let’s try some commands.

Running ext3grep:

# $IMAGE=/dev/sda1
# ext3grep $IMAGE --superblock | grep 'size:'
Block size: 4096
Fragment size: 4096

Using the options –ls –inode $N, ext3grep lists the contents of each directory block of inode N. For example, to list the root directory of a partition:

# ext3grep $IMAGE --ls --inode 2

It is also possible to apply filters to the output of –ls. An overview of the available filters is given in the output of the –help option:

# ext3grep $IMAGE --help
[...]
Filters:
  --group grp            Only process group 'grp'.
  --directory            Only process directory inodes.
  --after dtime          Only entries deleted on or after 'dtime'.
  --before dtime         Only entries deleted before 'dtime'.
  --deleted              Only show/process deleted entries.
  --allocated            Only show/process allocated inodes/blocks.
  --unallocated          Only show/process unallocated inodes/blocks.
  --reallocated          Do not suppress entries with reallocated inodes.
                         Inodes are considered 'reallocated' if the entry
                         is deleted but the inode is allocated, but also when
                         the file type in the dir entry and the inode are
                         different.
  --zeroed-inodes        Do not suppress entries with zeroed inodes. Linked
                         entries are always shown, regardless of this option.
  --depth depth          Process directories recursively up till a depth
                         of 'depth'.
[...]

$ ext3grep $IMAGE --restore-file

the above command will create a RESTORED_FILES directory in your current directory and store the recovered files there.

Well, there are other lot of commands and options of manually recovering some small but important files, but I have to cut this article short as putting all that here would be duplicating the things. Above instructions should be good enough for recovering one or two directories or some important files. Do let me know if I have missed some important bits, I’ll update it.

– Sandeep Sidhu

↑