iPhone 3GS OS4 Upgrade
September 4, 2010 – 5:23 pm | One Comment

iTunes for Windows must be one of the buggiest, most poorly written applications out there. In terms of wasted months of your life it definitely ranks up there with Lotus Notes and Media Player 12. I don’t know how well iTunes works on a Mac (I like computer mice with twenty buttons, so I never was a big Mac fan), but I think I read somewhere that iTunes for Windows is the leading cause of suicides among iPhone owners.

Read the full story »
Networking

Unix and Linux network configuration. Multiple network interfaces. Bridged NICs. High-availability network configurations.

Applications

Reviews of latest Unix and Linux software. Helpful tips for application support admins. Automating application support.

Data

Disk partitioning, filesystems, directories, and files. Volume management, logical volumes, HA filesystems. Backups and disaster recovery.

Monitoring

Distributed server monitoring. Server performance and capacity planning. Monitoring applications, network status and user activity.

Commands and Shells

Cool Unix shell commands and options. Command-line tools and application. Things every Unix sysadmin needs to know.

Home » Disks and Volumes

ReiserFS Filesystem Recovery

Submitted by admin on March 21, 2008 – 3:55 pmNo Comment
ReiserFS Filesystem Recovery

The this is a description of a method for recovering ReiserFS filesystems from failed disks with bad blocks, when other recovery methods (reiserfsck) will not work. For this example, the failed server is called node1 and the bad drive is /dev/hda1

Connect to the server and create an image of the affected disk on the /destination_fs filesystem. Note: the destination filesystem must bebig enough to fit all the data from the affected hard drive.

ssh node1 dd if=/dev/hda1 conv=noerror,sync > /destination_fs/hda1.img

Assign the created image to a virtual device:

losetup /dev/loop0 hda1.img

Re-build the superblock:

reiserfsck --rebuild-sb /dev/loop0

Find contents of missing directories:

reiserfsck --rebuild-tree /dev/loop0

Alternatives to try:

reiserfsck -S --rebuild-tree /dev/loop0
reiserfsck --check --rebuild-tree /dev/loop0
reiserfsck -S --check --rebuild-tree /dev/loop0

Verify contents:

reiserfsck –-check /dev/loop0

Mount the virtual device:

mount /dev/loop0 /mnt

View recovered data:

ls /mnt/lost+found

How to understand the lost+found
filenames. They are numbers of the form XXXXX_YYYYY and I found out
that the first part (i.e.) XXXXX is for the directory inode.

That is, let’s suppose we find a file called 3003_4004 in
/home/lost+found. And we have a user called “foo”, whose files we want
to recover. If we do

ls -i /home

it will show […] 3003 foo […]; gladly telling us that the directory
/home/foo has the inode 3003 and that file 3003_4004 once belonged to
that directory.

Now for an advanced situation: we have a 5005_42 file in
/home/lost+found and there is also a directory called 3003_5005. Well,
from the last paragraph we learned that 3003_5005 belongs to /home/foo.
But WAIT! 5005_42 belongs to the directory 5005! So u can copy 5005_42
into 3003_5005 and then 3003_5005 to /home/foo then, after crawling
into the files/dirs, rename them properly.

Popularity: 4% [?]

Related posts

Leave a comment!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.