ReiserFS Data Recovery Tips
By thegeekster at 2004-06-10 08:40
ReiserFS Data Recovery Tips
DISCLAIMER: This article is not to be taken as an authoritative, or definitive, guide on the subject. I cannot make any guarantee you will be able to recover your data using the steps outlined here. I will not be held responsible for any other loss of data or other damages that may occur. I am only passing on my experiences for you to do with as you see fit.
It seems there is very little on the subject of recovering data on a Reiser filesystem. After a mishap of my own making where I ended up deleting all the files on a partition and leaving only the directories, I searched high and low for info on recovering data on a reiserfs partition. I found a few open source tools and kits for Ext2/Ext3, but none for ReiserFS except for commercial data recovery tools which can cost a bundle. Even the ReiserFS support page charges 50 dollars per hour (25 dollar minimum). Since this was not a critical loss, I decided to keep looking.
So what's a person to do on their own for recovering files on a Reiser filesystem. Well, I finally came across on article at Sig9.com, titled Adventures in Undeleting by POLAX, which had something useful on recovering files for a ReiserFS partition (see link below).
WHAT TO DO
Here are steps I highly recommend to take when discovering any problems with the filesystem.
Now you're ready to use one of the following recovery methods. However, before we go into the method specific to ReiserFS, I must first mention the time-tested Unix method of recovering text using grep. The other method involves scanning the whole partition and will recover everything it can find, maybe even files deleted years ago.
- 1) DON'T PANIC. I'm serious. POLAX gives the same advice in his article and I agree. If you're in an excited state of mind, you're bound to make matters worse. Take a few deep breaths before proceeding. (Swearing is still allowed, just no hyperventilating. ;-))
2) As soon as you discover the problem, YOU SHOULD UNMOUNT THE AFFECTED PARTITION(S) FIRST THING!! Stop whatever you're doing and unmount the partition. Sometimes, the partition may refuse to be unmounted because it's too busy. In that case, use the -l option, which basically removes the filesystem from the hierarchy while letting it cleanup its act as soon as it can. So the command will look like this:
If you only have one partition for the whole OS, then shutdown the operating system, grab a rescue CD (or live CD) and boot into that. Make sure it supports ReiserFS.
umount -l /dev/xxxx
3) You will need to make an inventory of sorts by remembering anything about the files and or directories that are missing and writing it down. It may be helpfule to remember what files and directories are currently present on the filesystme in question.
4) Make a backup copy of the partition(s) before proceeding. If you have the room, work from the copy and keep the original intact. That way if you make a mistake, you can make another copy to use. If you don't have the room, try to make an image of the partition to tape or CD, and keep it handy.
The easiest method to make a copy is to create a separate partition of equal size and use the 'dd' command to copy the old to the new:
where old is the problem partition and new is the newly created partition. You will not need to mount the partitions for this to work, however, you must have the proper permissions to access the block devices (such as root priveleges).
dd if=/dev/old of=/dev/new
If you're strapped for space, then you will need to make a copy using some third-party tool for creating backup images of the partition that will write to tape, CD or some other backup device. Be sure to create a raw image that copies every single byte of data at the disk sector level. (Tar will not work here, it must be an image.) In other words, you need an exact copy down to the last bit on the disk.
NOTE: You may skip this step if you only need to recover some text files using grep. Just be sure to save the output to a different partition.
If you simply need to recover some text files, then this method is probably the best. It involves using grep on the block device (/dev/xxxx). The basic command looks like this:
Okay. let's break it down a little for those not quite familiar with using grep. The first option, -a, tells grep to process everything as text. -B outputs the number of lines BEFORE the text being searched for, and -A outputs the number of lines AFTER the search pattern. The 'search pattern' itself can be text or a regular expression search pattern. Here's an explanation of the options taken from the grep manpages:
grep -a -Bnnn -Annn 'search pattern' /dev/xxxx
Also, there is one more option not found in the manpages. Specifying a number of lines without using -A or -B is the same as using the same number for _both_ options. For example, using -10 will output 10 lines of text before AND after the text being searched. One other thing. If using a regular expression for the 'search pattern', be sure to enclose it in single quotes ( ' ). If fact, this is a good habit to get into for any search term when using grep.
-A NUM, --after-context=NUM
Print NUM lines of trailing context after matching lines. Places a line containing -- between contiguous groups of matches.
-B NUM, --before-context=NUM
Print NUM lines of leading context before matching lines. Places a line containing -- between contiguous groups of matches.
Process a binary file as if it were text; this is equivalent to the
If the first few bytes of a file indicate that the file contains
binary data, assume that the file is of type TYPE. By default, TYPE
is binary, and grep normally outputs either a one-line message saying that a binary file matches, or no message if there is no match. If TYPE is without-match, grep assumes that a binary file does not match; this is equivalent to the -I option. If TYPE is
text, grep processes a binary file as if it were text; this is
equivalent to the -a option. Warning: grep --binary-files=text
might output binary garbage, which can have nasty side effects if the output is a terminal and if the terminal driver interprets some of it as commands.
Notice the warning in the --binary-files=TYPE explanation. It says screwy things can happen to the terminal screen if you output the search results to the terminal because of any non-text, binary characters that may appear with the text. This warning also applies to the -a or --text options as well. And I can verify that it's true. The background changed color on me from black to light blue and the text on the screen suddenly became nonsense. I had to logout of that session and start a new one for things to return to normal. But there's a way to avoid this, which we will get to next. :-)
As mentioned in the preceding paragraph, you may get more than plain text in the output. Fortunately, there is a way to filter out the garbage using another handy command in our arsenal of commandline tools called strings, whose sole purpose is to find printable strings in a file. strings takes it's input not only from a file, but also from standard input, meaning input can be piped to it from another command on the command line. So, now we can clean up the output from grep by piping it to strings:
Now we will have a much nicer looking ouput to make it easier searching for that text file we're looking for.
grep -a -Bnnn -Annn 'search pattern' /dev/xxxx | strings
To complete the picture, redirect the output to a temporary text file:
This will output all the strings it finds, based on the search parameters, into a single file. It will be your job to look through that file to find what your looking for. Just make sure it get written on a different partition than the one being grepped. If the grepped partition is not mounted to begin with, there shouldn't be any problem on that score.
grep -a -Bnnn -Annn 'search pattern' /dev/xxxx | strings > text_dump
Okay, now we come to the main reason for this article, recovering all the files from a Reiser partition using only the tools that ships with the Reiser filesystem. Actually, there is only one tool that is needed, reiserfsck.
According to POLAX's article, two options need to be used with reiserfsck, -S and --rebuild-tree. The whole command looks like this:
In order for this to work, the partition MUST be unmounted. Otherwise it will refuse to do anything. You will also be required to type the word Yes when asked if you are sure you want to do this. You will get some scary looking warnings, but if you've made copies of the partition, then you won't need to worry much. If something bad happens, like a power failure, you always can start over.
reiserfsck --rebuild-tree -S /dev/xxxx
The --rebuild-tree option does what it says, rebuild the filesystem tree. The -S option tells it to scan the entire partition. And /dev/xxxx is the block device being rebuilt. Here're the explanations from the reiserfsck manpages:
I've included the option to write output to a logfile. This is not absolutely necessary, unless you want a record of whatever problems it found.
This option rebuilds the entire file system tree using leaf nodes found on the device. Normally you only need this option if the --check option reports "corruption that can be fixed only during --rebuild-tree". You are strongly encouraged to make a backup copy of the whole partition before attempting the --rebuild-tree option.
This option causes --rebuild-tree to scan the whole partition, not only used space on the partition.
-l file, --logfile file
This option causes reiserfsck to report any corruption it finds to the specified log file rather than stderr.
After that's done, mount the partition. If everything goes okay, you will have everything returned to you. More likely, though, you will get more than you bargained for, meaning everything that can be found will be returned. And if it can't find a name or location for the file, a lost+found directory will be created for dumping everything into, much like what a junk drawer is used for.
In this lost+found directory, you won't see any easy to recognize filenames. Everything is named with a numbering system similar to nnnnn_nnnnn where each group of numbers, before and after the underscore (_), is from one to five digits or more.
Now the real work begins. You will need to go through all those files and directories in lost+found and try to make sense of them by opening them up and taking a look. From what I've been able to determine, the first goup of numbers that precede the underscore have to do with location. In other words, if several files or directories have the same number in front of the underscore, they most likely came from the same directory.
Therefore, to make it easier to deal with the lost+found, put all the files and directories that have the same first number (the one before the underscore, nnnnn_) into their own directory, separate from the rest. After that's done, it should be a little easier to go through it and identify what to keep and what to throw away. When opening up some of the text files, there may be a few that are unreadable with non-text characters. Nothing can be done about that. Just do the best you can and hope for the best.
One more thing here. Even if files and/or directories get named correctly, they may be put in the wrong place. I'm referring to files and directories not placed in lost+found. So you will need to go through _everything_ to try to make sense of it all.
I hope this has been of some help. Basically, the overall idea is to first use grep if you only need to find a few text files and use reiserfsck if you need to repair the whole partition.
Remember, this is not a definitive guide. I don't pretend to be an expert on the subject. I can only pass on what experience I have in the matter and it is up to you to accept or reject it. If it's really that critical, then you should probably use the services of a data recovery specialist rather than do it yourself.
The last few links deal with Ext2/Ext3 and not ReiserFS, but they are still widely-used Linux filesystems and should be read as well.
All times are GMT -5. The time now is 08:06 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.