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