Share your knowledge at the LQ Wiki.
Go Back > Linux Answers > Hardware
User Name


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, titled Adventures in Undeleting by POLAX, which had something useful on recovering files for a ReiserFS partition (see link below).

Here are steps I highly recommend to take when discovering any problems with the filesystem.
  • 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:
    umount -l /dev/xxxx
    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.

    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:
    dd if=/dev/old of=/dev/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).

    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.
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.

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:
grep -a -Bnnn -Annn 'search pattern' /dev/xxxx
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:
-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.

-a, --text
Process a binary file as if it were text; this is equivalent to the
--binary-files=text option.

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.
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.

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:
grep -a -Bnnn -Annn 'search pattern' /dev/xxxx | strings
Now we will have a much nicer looking ouput to make it easier searching for that text file we're looking for.

To complete the picture, redirect the output to a temporary text file:
grep -a -Bnnn -Annn 'search pattern' /dev/xxxx | strings > text_dump
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.

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:
reiserfsck --rebuild-tree -S /dev/xxxx
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.

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:
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.

-S, -scan-whole-partition
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.
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.

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.

Suggested Reading:
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.

by thegeekster on Thu, 2004-08-26 14:41 seems the URL to the article I mentioned, called Adventures in Undeleting, is broken in the time I first submitted my article and when it finally appeared in LQ..................

I did make a copy of that article at the time I first came across it for my personal use, and if I can find the author, POLAX, I will ask his permission to post the copy here for everyone's benefit.........


by jeremy on Thu, 2004-08-26 15:35
Thanks thegeekster.


by thegeekster on Thu, 2004-08-26 19:58
Okay, after digging around a bit, I found the article...............It seems the "/forum/" postings are now in "/blog/", so that article, Adventures in Undeleting, has a new URL..............


by jeremy on Fri, 2004-08-27 08:53
The article has been updated.


by thegeekster on Fri, 2004-08-27 13:45

by kostian on Tue, 2004-12-14 07:23
just wanted to say thanks, this really helped me after ive rm -rf my /etc the other day
sure it was just /etc and you cant kill slack that easy but there were few configs i would like to keep.
and yeah make backups and actually read before you press enter when doing rm -rf on something as root on a Sunday morning

by JZL240I-U on Fri, 2005-02-18 08:07
Hm. Perhaps a silly question. Why the use of grep? I mean, in that case you have to remember a text-(snippet) to start it or just grep * when you want to recover all text files. So why not use
dd if=/dev/hdxy | strings
Should be much faster on a large partition without pattern matching and still deliver all text...

Furthermore, would your scheme work also on Reiserfs with LVM (logical volume manager) or is Reiserfscheck constrained to physical partitions?

by Oliv' on Sun, 2005-04-10 12:25
just a big Thanks to you thegeekster...
your article helps me a lot to recover a file which was mis-ovrewritten due to the crash of the appli
Note that the URL about Adventures in Undeleting is broken

by thegeekster on Sun, 2005-04-10 19:03
Originally posted by Oliv'
just a big Thanks to you thegeekster...
your article helps me a lot to recover a file which was mis-ovrewritten due to the crash of the appli
Note that the URL about Adventures in Undeleting is broken
Thank you. I'm glad it was helpful........

As for the broken link, I know about it, and it is no longer at the site, period..........However, last month the author of that article was looking for it (through Google) and was pointed to my article.............Seems he was looking for it online and couldnt find it so he emailed me and asked if I still had my local copy of his article and also told me he would release his article under this Creative Commons License.....

I've been meaning to post his article here at LQ since I have his permission, but haven't been able to get to it just yet..........Hopefully soon, though, as it contains some really useful information..........

by thegeekster on Sun, 2005-04-10 20:00
Originally posted by JZL240I-U
Hm. Perhaps a silly question. Why the use of grep? I mean, in that case you have to remember a text-(snippet) to start it or just grep * when you want to recover all text files. So why not use
dd /dev/hdxy | strings
Should be much faster on a large partition without pattern matching and still deliver all text...

Furthermore, would your scheme work also on Reiserfs with LVM (logical volume manager) or is Reiserfscheck constrained to physical partitions?
First off, sorry for the late reply.......I haven't been online very much in the last few months........

When using grep, it's easier to grep the whole partition, unless you know _exactly_ what you're looking for and how many lines to include before and after........The reason for using grep I got from one of the recoverNet links: recoverNet - Unix-section, which describes using grep as I outlined it in my article........But, I don't see any reason for not using dd in place of grep as long as the output file is written to another partition so as not to corrupt the one you're searching on (ie, unmount it before the search to avoid accidently writing to it).......

And, sorry, I don't know anything about LVM, so I can't help you there............I've never set up logical volumes but, as I understand it, the linux kernel uses device mapper to allocate space with the userland LVM tools, and the volumes have their own device designation..............So wouldn't the partition tools work as expected, since you are partitioning a volume instead of a disk?............Again, I'm not real sure how it works, but it seems like it would work, unless I'm missing an important piece of the LVM puzzle.........


All times are GMT -5. The time now is 11:14 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration