Linux File Recovery Study

Background

Today I did stupid things that I went into the ~/Downloads/ and pressed [Alt] + [A] then [Shift] + [Delete]. Wtf... I didn't want to delete this folder but another sub-folder...... So no zuo no die : )

Theory

• Generally, Linux filesystem mainly contains inode and blocks. inode is the index of file or directory; blocks stores the actual data.

• Usually, our rm or [Shift] + [Delete] in GUI just modify the inode but do not rewrite the blocks in which your data has ever be (If you use some special professional softwares to delete file, good luck : ) ).

• So if our file is just there as it was before if we take measures in time. We can't use filename or inode to fetch it, but there are other probably ways to make it.

• EMPTY. I want to add more filesystem knowledge here later. Remind me of it, OK ?

P.S. The filesystem is very interesting. You can regard it as local Domain Name System to some extent. And the filename is something like the domain name, while inode is something like IP address.

Recovery

Environment: Linux (I tried on Ubuntu 14.04 & CentOS 6.0)
Filesystem: Ext4 [1]
Of course, you'd better be root and everything will be easier.

0x0 Forbid other users and processes to Modify the filesystem

~If no speical prompts, you'd better follow this part to protect your data.
~Now we test on /dev/sda8 mounting at /tmp. sth in /tmp may be erased after mounting or unmounting, but sth in /tmp/lost+found may not.
～I use cat /proc/meminfo > /tmp/lost+found/tet to create a test file and delete it.
~fs means filesystem.
~sth means something.

For the test, I md5sum /tmp/lost+found/tet before deleting it

Before unmounting, use ls -id /tmp and take down the inode number

1. use df or fdisk -l to determine the fs to be unmounted

2. unmount it: umount /dev/sda8
   

3. mount the fs with read-only state: mount -r -n /dev/sda8 And you can have a try to write sth and find failed.

P.S.
~When I man umount I found umount /dev/sda8 is not recommended and it's better to use umount /tmp (directory name). And after I mount -r -n /dev/sda8, I failed to use umount /dev/sda8 to unmount it.
~If the fs is busy and you can't unmount it. You can use fuser -v -m /dev/sda8 to find the processes using it and kill them. What's more, you can use fuser -k -v -m /dev/sda8 to kill them automatically.

Here I will give some methods I have tried(the title is the main tool to be used).

0x1 extundelete

• yum install e2fsprogs e2fsprogs-libs e2fsprogs-devel
• wget http://tenet.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.bz2
  If you didn't install g++ like me, yum install gcc-c++
• ./configure
• make && make install

• extundelete /dev/sda8 --inode 2 to check
  

• extundelete /dev/sda8 --restore-directory lost+found
  here I use --restore-directory, you can also use --restore-file RELATIVE-PATH-OF-FILE

• md5sum ./RECOVERD_FILES/lost+found/tet
  

Bingo~

P.S.
You can also use extundelete /dev/sda8 --restore-all simply.

0x02 debugfs & dd

...

0x03 testdisk

...

Finally

Some advice:

• Backup is very very important
• Disk should be parted into filesystems (/,/home,/boot,/var,/usr,swap,...)
• alias rm="rm -i"

Quotations

I learnt knowledge from articles below. Thanks for the authors' sharing.

• linux rm -rf * 文件恢復記
• extundelete實現Linux下文件/文件夾數據恢復！

Appendix

[1] How to determine your filesystem?

1. fdisk -l # to get the name of disk. E.g. /dev/sda5
   You can also use df and this tool can show the relationship between fs and your directories. However, this tool can only deal with fs being mounted.
2. file -s /dev/sda5