geek

Here’s the story of how i rescued a Windows XP installation from a broken 160 GB SATA hard disk to an intact 60 GB SATA disk, illustrated in a few easy teps that will make my six and a half hours of creative hackery seem like a work (walk) in the park. I also sing high praise to the penguin.

But first a disclaimer, since my boss will probably be reading this.  All this could probably have been done using suitable tools running on Windows. We just don’t have any. Also, you could probably have done this using partimg, saving you a bucketload of work, but since you’re doing this from a broken disk, partimg will puke and fall over.

Here’s the brief background. A few days ago, i heard from a customer that one of their laptop hard disks had broken. Today, while waiting for the replacement HD, i got an update. The guy with the broken laptop is going on a business trip to see some customers and that he needs a laptop with him. So if either that one could be repaired, or if i could get a spare laptop of theirs in running order, that would be, well, critical. Deadline in 24 hours, preferrably less.

This would have been easier if we actually had had a replacement hard disk for his machine, or had not the replacement laptop been “slow to boot” (ie either full of viruses/worms/crapware or just decomposed). Now it was a no-win in either direction.

Step 0: Sanity check

To successfully perform this trick, you need a spare hard disk, cannibalized from your demonstration station, an external HD, and a wonderful little distribution called System Rescue CD. Oh, and a lot of coffee. Optional extras, which would have been nice, would have been a SATA adapter so that you can have two laptop HDs plugged in at the same time, a second copy of System Rescue CD, and the same number of power bricks that you have laptops to work with. I did this with two laptop, one Rescue CD (stupid) and one power brick (equally stupid). If you have only one laptop to work with, be prepared to plug and unplug hard disks plentiful times, and try to compensate my scribbling with your manifestation of reality. I could probably rewrite this article with a more optimal setup, but then it would seem even less heroic.

Oh, also a functioning computer that you can have for reference and to play music from is essential

Now before i let you get your hands in the mud, realize that the narrative that follows is just that. A narrative that follows. I can’t take any responsibility if you follow the story below to the comma and a small black hole appears in the middle of your living room that sucks everything into it and reality just ends and the whole thing just ruins your day. If you’re unsure of what i’ve written and the correctness of it, assume i’ve made a mistake and stop right there.

Now let’s get our hands in the mud.

Using, for instance, the laptop’s HD checking tool built into the BIOS, make sure that the hard disk actually is broken. Remember: “Patients lie.”

If your source disk fails, now would be a good time to label your disks (dymo, magic marker, whatever) and your computers, since on the outside they look very much alike when you can’t boot onto them to see which box really is which.

If your source disk actually hasn’t failed yet but only show signs (or sounds) of age, i’ve added how to do this in way fewer steps at the end.

Step 1: Make “just-in-case” backups

This step is completely optional, but since you’re soon going to do irreversibly damaging things to your source hard disk, it’s probably a Really Good Idea to follow. Also, you’re going to repeat this step soon, so why not practice now when it’s not irrevocably dangerous?

Boot the “broken” laptop with System Rescue CD. Plug in the external HD, which needs to have more free space than the HD you are going to rescue, and needs to be formatted in a way that supports gigantic files (ntfs, ext3). Mount the external hard disk as /mnt/brick (or whatever you like). Figure out, using fdisk -l /dev/sdX, which hard disk it is that you’re trying to rescue. Mine was /dev/sda and the brick was /dev/sdb.

Make a backup copy of the master boot record (MBR) using the following two commands (substituting paths where necessary):

dd if=/dev/sda of=/mnt/brick/backup-sda.mbr count=1 bs=512
sfdisk -d /dev/hda > /mnt/brick/ backup-sda.sf

(tip taken from here). Without the MBR, the computer Just Won’t Boot even if everything else is restored. This i realized only after everything else was restored but hey, i’m nice and i’m writing it here where things are still simple.

The reason why you’re using dd and sfdisk to back up the MBR is that while the Windows XP restore disk has the very convenient tool fixmbr and was provided with your nice HP laptop, it does not include SATA drivers so it won’t see that you have a hard disk on your computer to fix the damn MBR on. Or in essence, it is a useless piece of compressed polycarbonate and it should be a criminal offence to ship it as such as a restore disk. Also, the Vista installation disk you have backstage will not bother running a restore console on an XP installation. Well, mine didn’t. (End rant)

Back up the hard disk using ddrescue, make a backup of the b0rken hard disk. If your paths are like mine, the syntax is ddrescue /dev/sda1 /mnt/brick/sda1-backup /mnt/brick/sda1-backup.log and what it does is copy the first partition of the disk sda onto a file named sda1-backup on the external hard drive and using a log file in case things go haywire. This will probably take a an hour or two. Send St. Anthony some warm thoughts, just in case.

Nota Bena: If you have the two laptops up and running at the same time (because you have two System Rescue CDs), remember to sync and umount the it before pulling the plug and connecting it to the other lappie. If you’re on a gigabit network, screw USB hard disks and copy over the net instead. If you have just one of the lappies up at a time (because you have just one power brick :)) you’ll need to go through the mkdir /mnt/brick && mount /dev/sdb1 /mnt/brick hoop after each startup. Oh, and make sure /dev/sdb1 actually is your external HD brick

Step 2: Prepare the target disk

As mentioned, we had a spare disk that was smaller than the disk that had broken. Fortunately, the amount of stuff on the broken source disk was lesser in size than the capacity of the target disk. This is where the dangerous fun parts begin.

Boot a laptop with the target disk using System Rescue CD, or plug it into the system you got running in the previous steps using a SATA adapter/enclosure/doohickey/thingamajig. Give a sigh to the installation you have on it, back up the valuable stuff from it onto the external hard disk. If you haven’t yet done so, start XWindows using the command wizard. Plow through the options until you have a graphical user interface. Start GParted by clicking the icon with the disk symbol. Make really really really sure you are selecting the right disk unit (this is why it might be good to boot up the computer with only that disk connected, and to unmount and unplug the external HD before you commence with the following) and delete all partitions there are on the target disk. Create a new NTFS partition on the disk, filling all of it. Then, using the resize/move partition button, make a note (pen and paper, baby!) how many MBs the partition is. Then, just for good measure, using fdisk -l /dev/sda (assuming the disk you just repartitioned is sda) write down the size info you get there too.

And you think that was scary?

Step 3: Resize the source partition

Go back to the laptop with the broken hard disk. Get GParted running on it like in the step above. Grab that /dev/sda1 partition and Resize it into the exact number of MB as your target disk’s image is, the one you made notes of in the previous step. Breath normally (if you can). Oh, and remember to run the computer on a power brick, not batteries, while you do this. It feels much better. I promise.

At this stage, half of your system probably thinks that the /dev/sda1 partition is still of the previous larger size. If you feel unsure, run fdisk -l /dev/sda to check. Or reboot. Or something.

Step 4: Back up the resized partition

Again, using ddrescue, back up the the partition you just resized to the external HD. You’ll probably need to run through the mkdir /mnt/brick and mount /dev/sda1 /mnt/brick hoop again if you’re running with just one System Rescue CD (and one power brick). In case you have both lappies running, i suppose now is a little to late to remind you that you need to sync and umount the /mnt/brick before swapping it between laptops. If you didn’t, your data is probably fried at this stage, so start from the top. Don’t say i didn’t tell you before, because i just added that bit (see, i can write in a nonlinear fashion even if you’re probably reading this from up to down). Then back up the MBR as outlined in step 1.

Thinking of it, you might as well first back up the MBR and then back up the data, since backing up the data is going to take a lot longer than backing up the boot record. Still, since you just made the data partition smaller, it’s not going to take as long as in the previous data backup phase. If you’re running short on disk space on the external brick, it’s probably faster to run down to the chip shop and get a new disk than trying to gzip the original image, even if the chip shop is closed. OK, down to business.

Suggested syntax:
dd if=/dev/sda of=/mnt/brick/resized-sda.mbr count=1 bs=512
sfdisk -d /dev/hda > /mnt/brick/resized-sda.sf
ddrescue /dev/sda1 /mnt/brick/sda1-resized /mnt/brick/sda1-resized.log

Again, be sure of yer paths yadda yadda (hey, we’re all grown ups so we can take care of ourselves so i’ll stop warning you at this stage).

Step 5: All pieces fall together nicely

Right then, time to put all your pieces together. The partimg manual (linked to in step 1) suggests now would be a good time to restore your resized partition table to the empty disk. I didn’t, because i only realized later copying the MBR is a mandatory step if you want the target box to boot. So it will probably work if you do it in the wrong order too. But i’ll document the procedure here in the supposedly correct(er) order.

Boot the computer with the blank NTFS-formatted hard disk (which we suppose is /dev/sda — oh that’s right, i said i wouldn’t be warning about paths anymore) and the external USB brick plugged in.

dd if=/mnt/brick/resized-sda.mbr of=/dev/sda
sfdisk /dev/sda < /mnt/brick/resized-sda.sf

…and a fdisk -l /dev/sda, a sync and/or a reboot if you weel wobbly. Could be the coffee at this stage though.

Finally, restore the resized partition image onto the new disk:

ddrescue /mnt/brick/resized-sda1 /dev/sda1 /mnt/brick/resized-sda.restore-log

Step 6: The resurrection

Place the restored hard disk in the laptop which used to house the broken disk. Boot that laptop. Be very, very satisfied. Buy yourself a chocolate, because you’re worth it.

Post mortem

I could probably re-write this article using a more optimized setup. But then again, i started with a way more complicated question which was “how can i resize the backup image i’d taken and fit it on the target disk?”. Turned out it was easier to just resize the broken partition and dump that on the new disk. Also, backing up my 160 gig backup image (i’d rather be careful than sorry) from and to the same external USB hard disk took sooooooo long that i was going to see sunrise before a complete copy.

An easier solution that wouldn’t have worked

Here’s how to do this whole trick if your hard disks aren’t broken just yet. Or if you’re migrating to a larger/smaller HD and don’t want to install everything anew. I’m going to assume this time that you’re doing it on a computer where you can have both disks plugged in at the same time. I’m also going to assume you’re only going to move/rescue a disk with one partition. If there are more partitions there, you’ll have to improvise a bit. They’ll all be copied though, but i’ll leave the particulars to you, the enlightened reader.

Finally, i’m assuming that you’ve read the whole article down until here because i’m not going to repeat how you’re going to do it here. If you haven’t, start from the top and i’ll be waiting right here until you’re through, okay?

Case 1: Identical source and target disks

Plug in both hard disks. Boot with System Rescue CD. Verify that your source disk is /dev/sda and your target disk is /dev/sdb (and not the other way around or your data will be forever fried — you might consider making a backup at this stage eg by mounting one of them and checking what’s inside.

ddrescue /dev/sda /dev/sdb transfer.log

Wait. Reboot. Rejoice. Piece of cake.

Case 2: Target disk is larger than source disk

Plug in both disks. Boot with System Rescue CD. Verify /dev/sda is your source disk and /dev/sdb is your target disk as above.

ddrescue /dev/sda /dev/sdb transfer.log

Wait.

Start XWindows. Start GParted. Select target disk from the less-than-obvious drop down at the near top right corner of the GParted window. Resize target disk to maximum. Apply.

Reboot. Rejoice. Cake with crusting.

Case 3: Target disk is smaller than source disk

This is what i should have done (see, now i spoiled my own thunder) and is more or less a more efficient re-write of this whole article up until now.

Plug in both disks. Boot with System Rescue CD. Plug in external HD brick. Mount as above to /mnt/brick. Make a backup of the source disk’s MBR if you’re nervous/careful/pedantic. Back up the source disk, just in case (optional for the brave/foolish).

ddrescue /dev/sda /mnt/brick/sda-backup backup.log

Start XWindows. Start GParted. Select source disk. Resize the partition so that it’ll fit on the target disk. Move your pr0n/mp3s/dvdrips to external brick first if required. Exit GParted. Take a deep breath.

ddrescue /dev/sda /dev/sdb transfer.log

Wait. Restart GParted. Resize your newly transferred /dev/sdb1 to fill all of the disk. Apply. Sync. Reboot. Rejoice.

And that’s about the size of it! Oh, and these tricks would probably have worked equally well for backing up other Windowsen, Linuces and OSXen. I just didn’t try.