Undelete utilities for Linux are few and far between. The Linux philosophy is that users shouldn't delete files they really don't want to delete, and if they do, they should be restored from backups. Nonetheless, in a pinch there are some tricks you can use to try to recover accidentally deleted files.
Note Low-level disk accesses require full read (and often write) privileges to the partition in question. Normally, only root has this access level to hard disks, although ordinary users may have such access to floppies. Therefore, normally only root may perform low-level file recoveries.
One of these tricks is the recover utility, which is headquartered at http://recover.sourceforge.net/linux/recover/ and available with most Linux distributions. Unfortunately, this tool has several drawbacks. The first is that it was designed for ext2fs, and so it doesn't work with most journaling filesystems. (It may work with ext3fs, though.) Another problem is that recover takes a long time to do anything, even on small partitions. I frequently see network programs such as web browsers and mail clients crash when recover runs. Finally, in my experience, recover frequently fails to work at all; if you type recover/dev/sda4, for instance, to recover files from /dev/sda4, the program may churn for a while, consume a lot of CPU time, and return with a Terminated notice. In sum, recover isn't a reliable tool, but you might try it if you're desperate. If you do try to run it, I recommend shutting down unnecessary network-enabled programs first.
Another method of file recovery is to use grep to search for text contained in the file. This approach is unlikely to work on anything but text files, and even then it may return a partial file or a file surrounded by text or binary junk. To use this approach, you type a command such as the following:
# grep -a -B5 -A100 "Dear Senator Jones" /dev/sda4 > recover.txt
This command searches for the text Dear Senator Jones on /dev/sda4 and returns the five lines before (-B5) and the 100 lines after (-A100) that string. The redirection operator stores the results in the file recover.txt. Because this operation involves a scan of the entire raw disk device, it's likely to take a while. (You can speed matters up slightly by omitting the redirection operator and instead cutting and pasting the returned lines from an xterm into a text editor; this enables you to hit Ctrl+C to cancel the operation once it's located the file. Another option is to use script to start a new shell that copies its output to a file, so you don't need to copy text into an editor.) This approach also works with any filesystem. If the file is fragmented, though, it will only return part of the file. If you misjudge the size of the file in lines, you'll either get just part of the file or too much—possibly including binary data before, after, or even within the target file.
Was this article helpful?