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

The hexdump didn't show up anything of importance (or so I thought.) I now had the option of writing back the ddrescued image or zeroing the blocks. This forces the disk to mark the blocks as bad and reallocate. I opted for zeroing as I didn't want any future problems to be masked by the attempted recovery. This was followed by a non-destructive read-write test on the full disk ensured that I'd got all the bad blocks;

# dd of=/dev/sda1 if=/dev/zero bs=1024 seek=19519872 count=1
# dd of=/dev/sda1 if=/dev/zero bs=1024 seek=19519892 count=112
# badblocks -v -o bad-2.txt -n -s /dev/sda1

A succession of reboots and chkdsk's later got me back to the XP login screen. The side effect of zeroing the bad blocks appeared to be losing the Windows license which prevented any kind of login. This may have been prevented by writing the bad blocks with the recovered image. A re-installation of XP corrected the problem with no loss of data.

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

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

#

So, no joy there. A hexdump of the image shows that the first 0xa0000 bytes were corrupted. There should at least be a partition table there.

# hexdump -C key.img | head
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000a0000  eb 3e 90 4d 53 57 49 4e  34 2e 31 00 02 04 01 00  |.>.MSWIN4.1.....|
000a0010  02 d0 02 00 00 f8 f9 00  20 00 ff 00 00 00 00 00  |........ .......|
000a0020  00 e2 03 00 80 00 29 aa  70 ac 30 4e 4f 20 4e 41  |......).p.0NO NA|
000a0030  4d 45 20 20 20 20 46 41  54 31 36 20 20 20 f1 7d  |ME    FAT16   .}|
000a0040  fa 33 c9 8e d1 bc fc 7b  16 07 bd 78 00 c5 76 00  |.3.....{...x..v.|
000a0050  1e 56 16 55 bf 22 05 89  7e 00 89 4e 02 b1 0b fc  |.V.U."..~..N....|
000a0060  f3 a4 06 1f bd 00 7c c6  45 fe 0f 8b 46 18 88 45  |......|.E...F..E|
000a0070  f9 fb 38 66 24 7c 04 cd  13 72 3c 8a 46 10 98 f7  |..8f$|...r<.F...|
#

A little bit of googling led me to this Linux Journal article and gpart. It sounds like gpart should do the trick of finding and identifying the lost partitions but I just wasn't able to make it perform.

Looking again at the hexdump above and that of another USB key it became clear that 0xa0000 was the start of the partition itself. All that was required was to mount it.

# mount -o loop,offset=0xa0000 -t vfat key.img /mnt/usb

I was then able to burn the recovered contents to CD and a happy writer got back her edited manuscript. The USB key is unusable - fdisk couldn't write a partition table back and it wouldn't format under Windows.

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