disc recovery – bloggingIT

Using dd and dd_rescue

Following up on a post about recovering bad disks and reiser file systems, here is a list of ddrescue commands to help make life that little bit easier:

Backup MBR (boot code + partition table):

<code>dd if=/dev/hda of=mbr count=1 bs=512</code>

Restore boot code + partition table:

<code>dd if=mbr of=/dev/hda</code>

Restore, not including partition table:

<code>dd of=/dev/hda if=mbr bs=448 count=1</code>

Saving partition sizes to text file:

<code>fdisk -l /dev/hda >partition-info.txt</code>

Backing up to gzipped file:

<code>dd if=/dev/hda | gzip >hda.gz</code>

Restoring:

<code>gunzip -c hda.gz | dd of=/dev/hda</code>

Backing up to archive split into 1GB chunks:

<code>dd if=/dev/hda | split -b 1024m -d - hda.</code>

Restoring:

<code>cat hda.* | dd of=/dev/hda</code>

Backing up over ssh tunnel to remote machine (blowfish = faster):

<code>dd if=/dev/hda | ssh -c blowfish user@machine "dd of=hda"</code>

copying files over ssh tunnel:

<code>tar cv /source | ssh -c blowfish user@machine "cd /destination ; tar x"</code>

Thanks to colinm over at Digg for putting these so succinctly

Recovering bad discs in Linux – pt 2

So, maybe in part 1 the data recovery didn’t work for you?

Well, that’s OK because Linux is robust against bad discs in one form or another. The trick is to work out what that might be.

A good method is to use dd or dd_rescue. These tools create a forensic copy of your hard disk drive or partition so that you can mess around with it without affecting the original drive. This is also a benefit as generally a virtual disk will mount and work faster than a faulty disk drive.

To begin with, we need to create that copy of the partition that you need data from.

mkdir ~/myDisks
dd_rescue /dev/hda1 ~/myDisks/hda1.image

The reason that I’m using dd_rescue rather than dd is that seeing as you’re reading this guide, the drive probably has faulty areas of the disk. dd_rescue will work around those quite nicely.

I’m working on the premise that it’s a single partition that you need to recover. If not, you may want to look over at http://edseek.com/~jasonb/articles/linux_loopback.html#id2494145 to read up on ways to read parts of disk images and generally show off.

Right, so we have our image.

Let’s set up the mount point

mkdir /mnt/restore

And now mount the new partition image

mount -o loop ~/MyDisks/hda1.image /mnt/restore

The partition should now mount on the folder. To check if anything is there:

ls /mnt/restore/

You should see a familiar list of files (or if someone else’s drive, one that is not so familiar). You can now copy the files away and do whatever you need to do to the image.

Once finished, unmount the disk image

umount /mnt/restore

Recovering a faulty hard disk drive in Linux – PT1

Today, I’ve been working on a server that doesn’t want to mount one of the partitions that has been formatted with reiserfs.

Using the fsck command doesn’t work because there are bad blocks on the drive, resulting in fsck vehemently refusing to cooperate.:

Cannot read the block (41713664): (Input/output error).

To get fsck to play with such a faulty device, you need to build a list of badblocks first, so that fsck can deal with them. If the disk is REALLY bad, then this will do no good at all – just dd_rescue that bad boy!

It’s never bad to backup before doing something like this anyway, so if you can – use dd_rescue to clone onto another disk. The likelihood is that you don’t have another disk and that’s why you’re reading this. If so, read on.

First of all, we need to be able to tell fsck which blocks on the disk are bad. To compile a list of badblocks, you’ll need to use the badblocks tool:

badblocks /dev/hda1 >>badblocks.txt

Obviously, change hda1 for the partition that is causing you trouble.

You may also need to specify a block size for the partition. The default is 4096, which is the standard size of reiserfs, but to be doubly sure, you can run the debugreiserfs command, and the output will show you the blocksize:

Blocksize: 4096

If the blocksize differs, run
badblocks -b 4096 /dev/hda1 >>badblocks.txt
replacing 4096 with your block size.

This may take some time. Grab a book, make a drink, have a snack.

Once the blocks have been read, enter less badblocks.txt to make sure that there is something in the file. You should see a series of numbers output to the screen. If that’s good, press ‘q’ to return to the shell.

Now to run fsck. We will need to account for the bad blocks, so you will need to include that badblocks file that you have just created:

fsck.reiserfs –fix-fixable -B badblocks.txt /dev/hda1. Once again, change the device from hda1 to what you are trying to recover. As long as the driver isn’t completely nerfed, the you might be able to run through the commands and recover the drive table.

If not, then I’ll have another article very soon.