How to recover a removed file under Linux?

Solution 1:

The following are generic steps to recover text files.

First use wall command to tell user that system is going down in a single user mode:
```
# wall
System is going down to .... please save your work.
```
Press CTRL+D to send message.
Next use init 1 command to take system to a single user mode:
```
# init 1
```

Using grep (traditional UNIX way) to recover files

Use following grep syntax:

grep -b 'search-text' /dev/partition > file.txt

grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt

Where,

-i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character.
-a : Process a binary file as if it were text
-B Print number lines/size of leading context before matching lines.
-A: Print number lines/size of trailing context after matching lines.

To recover text file starting with "nixCraft" word on /dev/sda1 you can try following command:

# grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt

Next use vi to see file.txt.

This method is ONLY useful if deleted file is text file. If you are using ext2 file system, try out recover command.

Found at http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html

Solution 2:

If it's very-very important, take the disk from the computer and hire a company to do it for you.
If it is only very important, mount the disk read-only, copy the whole partition to a file using dd and try to find the file within it (using grep, or an editor).

Edit: sometimes ddrescue works better than dd.

Solution 3:

If your filesystem is ext3, use ext3grep.

Solution 4:

Testdisk has an undelete option that should work with Linux.

There is a walkthrough for Linux. Note that it works for ext2, ext3, and ext4.

Solution 5:

I did this a couple of years ago. My approach was to directly, no time to lose, unmount partition and then

dd if=/dev/hda1 of=backup_image.ext3

to have a backup file of the exact state of the partition. Then you can mount the partition again and continue with business as usual as you search for the the deleted file in your created image. The image will probably be VERY large since you need all the "empty" space, so it might be a practical problem to store it.

Then it was just to perform boring searches after text snippets I expected to be somewhere in the soup of partition content. E.g. to find .tex-files, I ran

grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles

which printed a large context around the phrase "subsection" and saved the output to a file to be manually searched through. I printed such a large context since it took such a long time to search the image that I'd rather not do it more times than I had to.

Also the command strings was helpful in removing binary garbage from the output, but if I recall correctly it also stripped all newlines, which could be a problem.

To find binary files in the same way, one might have success in finding a characteristic header or something of a certain file, but I imagine it to be a rather big adventure.

Brief technical notes: there are technical difficulties with disk recovery and Ext3/4. It is a long thing to explain, but briefly (and inadequately): Ext3/4 removes the "markers" that tell the OS where files are located on disk when you delete them. The files aren't scrubbed, but no one knows where on the disk they start and end anymore, and sometimes they even are fragmented at several places. Some other file systems just set the files' statuses to "deleted", but keep the location data. Then undelete is not harder than to look at file pointers with this flag (they should still be available if not too much activity has occured), and then hope their content has not been overwritten.

What is best? Rhetorical, in my view. Frequent backup is the answer to all these problems. Important data without an automated backup system is an accident waiting to happen, IMHO.

Obligatory personal anecdote: I was going to remove foo\ foo* from ~. I wrote

rm -r foo<Tab>*

, which sadly, since foo apparently was a symlink and the only file matching this, the shell made into

rm -r foo\ foo *

I pressed Enter and sat there looking at the command, which should have taken a second at most. After a bit longer time rm asked me if I wanted "to remove the write-protected file 'something'".Quite quickly I felt the chills and softly and very controlled I pressed Ctrl+c. ~Half of my ~ was deleted, but I managed to get everything of value back through above described grepping and some more or less current backups. I had some personally very valuable (read: time consuming) and very recent measurement data on disk that was lost, but I had made quadruple backups. One disappared here, another due to system outage at school, another was corrupt, and at first I couldn't find the fourth, since I by mistake had put it in the wrong folder :-D . Had not rm -r got stuck on a write-protected file, the fourth would have been eaten since that folder was mounted via sshfs in my ~. I'm a lot more careful about that kind of stuff since.