ralf

Overview

As already described in the general article on ext3undel, if you want to recover a specific file you need a bunch of tools. Running the process manually consumes significant amounts of time - time, in which the relevant data already may be overwritten, and for sure the lost information is not available. So R.A.L.F. is an approach to automate the necessary steps - saving you from fiddling around with all the required information, and the work of manually combining them until you hopefully recovered what was lost.

Steps

So which steps are to be done - or, in other words, how does R.A.L.F. work?

1. Using the systems mount table, R.A.L.F. first determines on which device the lost file you specified was stored, and then asks you to specify a different device to store the recovered data on (to minimize the risk of overwriting data yet unrecovered).
2. It then runs fls to extract all iNode information available. Using grep, it restricts this information to deleted files which are (hopefully) recoverable, and within this information again it uses grep to find the file name you specified, together with the information of its iNode
3. If the iNode number for the specified file could not be found, R.A.L.F. offers to substitute the parent directories iNode instead. Though this is not that direct (and "safe") to identify the right data block range, changes are still good (since in many cases it will do) - as long as the data blocks are not reused already.
4. Based on the files extension, R.A.L.F. now offers to restrict the recovery to the matching file type (if any) and thus limit the result set. You may still decide to ignore that and recover everything possible from that data block range - though this only makes sense if the file type was not identified correctly. If no matching file type was found, it will do so either.
5. Having retrieved the iNode number in the previous step, R.A.L.F. now utilizes fsstat to dump the iNode group information: iNodes are organized in groups, and each group of iNodes has a certain range of data blocks assigned. So now this range is retrieved, so we can restrict our operations to a much smaller part of the partition in question.
6. Now we know where the file should be found - so those data blocks are extracted and written to a dump file (on the other device specified). This job is done by the dls tool.
7. Finally, R.A.L.F. runs either PhotoRec or foremost (depending on which is installed on your system) to extract the files from that image.

Remember, the complete information about the file is gone at the moment of deletion - so we cannot tell which of the files is the one you were looking for. Hence we need to extract them all, and then you need to investigate the results and find your file. But hey, that's much better than not to get it back!

Problems

So we can lean back - deleting of a file is no problem, since we always can restore it? NO! Not at all. There are moments a file cannot be recovered - even if you just deleted it only a second before:

• parts of the files data could already be overwritten
• the file itself may have been fragmented - so we probably only find the first fragment
• file system corruption could prevent us from having success
• the iNode information could already be lost - and the parent directories iNode group not matching the correct data block range
• R.A.L.F. itself could be nothing but a collection of bugs (oops
• the other tools used may also have some bugs

So don't be too relaxed about the issue. Though R.A.L.F. and the tools it is utilizing are there to help you in case of, there is no guarantee ever!