NTFS recovery with SpinRite

Some more corrupted sectors appeared on the same disk mentioned in this earlier post. Once again, the Windows recovery console was no help as it would just hang but I could access the disk after booting Linux and found the corrupted sectors using badblocks. I pulled the sectors off, as I'd done before, using ddrescue utility. Since the last failure was less than 6 months ago and there may be more failures to come I decided that paying $89 for GRC's SpinRite was more than justified.

What a fabulous utility! It was pretty easy to get up and running after downloading and burning a boot disk. I initially had a problem with the laptop CPU overheating and shutting down. This happened when SpinRite was trying to recover some lost sectors and vexing the CPU. Moving the laptop too a cooler location on top of a fridge did the trick.

It took a few hours to run through the disk and recover the sectors, where possible. I then rebooted in the Windows recovery console and ran chkdsk. Job done!

At the same time I ran SpinRite over my aging Dell C400's 80GB drive. This laptop is now used as a Linux MythTV frontend and has been making a few noises sounding a little like seek errors in the making. The hard disk was running a little hot during the scan which resulted in some temperature warnings SpinRite. Moving the laptop into the fridge solved the cooling problem and the scan continued uninterrupted. SpinRite found and recovered a few bad sectors on the ext3 partition and I have yet to hear the noise again.

posted by James Gemmell on Sun, 07 Feb 2010 at 17:21 | permalink | tags: recovery

Recovery from Windows XP chkdsk failure

My laptop started hanging at the Windows logo stage and successive reboots wouldn't fix the problem. Booting into the Windows recovery console and running chkdsk manually on the C: drive would hang at the 22% mark. Next I booted Trinity Rescue Kit 3.3. This Linux-based Live CD is essential to any system recovery arsenal. It can be booted from a USB stick and even a PXE network boot, if necessary. Bruce Allen's Bad block HOWTO for smartmontools is a great source of help. Its focus is Linux file system recovery but the techniques are readily adaptable to NTFS.

No obvious indications of errors were turned up using smartctl. The next thing I did was use badblocks to run a low level read-only test;

# badblocks -v -o bad.txt /dev/sda1

This came up with a list of 113 corrupted blocks starting at 19519872, which is roughly 22% of the way into the NTFS partition. There was a single block at this location and the remaining 112 in a contiguous segment starting at 19519892. I used dd and ddrescue to make a copy of the blocks and hexdump to have a look at the contents. ddrescue is one of the GNU utilities I've fortunately never had to use before. It is suited to recover entire disk images and has some smarts built in to recover problem areas.

# ddrescue -b1024 -i19519872b -o0 -s1b -t /dev/sda1 /tmp/bad2.img
# ddrescue -b1024 -i19519892b -o0 -s112b -t /dev/sda1 bad3.img
# hexdump -C bad3.img | less

Read more...

posted by James Gemmell on Sun, 30 Aug 2009 at 08:19 | permalink | tags: recovery

Corrupted USB flash key recovery

There are only two kinds of people in the world, those who have lost data and those who are about to. — Anon

The 128Mb Swisskey belongs to a friend and contained the only edited copy of a manuscript she has been working on. She had forgotten to "trash can" or eject it before removing it from her Mac and could no longer read anything from the key. It's doubtful whether the act of removing the key caused the corruption but there does seem to be a link.

The first thing I tried was reading the raw key image.

# dd if=/dev/sda of=key.img
500+0 records in
500+0 records out
131072000 bytes (131 MB) copied, 132.2937 s, 1.0 MB/s
#

I repeated this step to create another image file and then compared their md5 signatures to make sure the key wasn't corrupting the data itself. The next thing I did was try to mount the image.

# mount -o loop -t vfat key.img /mnt/usb
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

#

Read more...

posted by James Gemmell on Thu, 15 Mar 2007 at 10:31 | permalink | tags: recovery