Drive: WD5000AAKS 00TMA0
Date: 28 Jun 07
DCM: DHRCHV2CHB
PCB: 2061-701477-800AF XT 4D07 85K5 6 0004500 7 504

System 2x500 GB drives mirrored (AAKS & AALS)

The first drive, AALS, died making the always bad scratching sounds 3 days ago. Sent it away for warranty replacement.
Purchased a replacement AALS drive in order to mirror the AAKS drive. Upon reboot the AAKS drive is recognized in the BIOS, however the linux kernel is giving DRDY/DMA messages. There are no abnormal knocking or scratching sounds, the drive spins up, seeks and tries again rhythmically.

There were no slowdowns or SMRTCTL messages prior to initiating the reboot in order to mirror the drive.

This isn't the end of the world, as there is a 23 Apr offsite backup, but being the end of the week (and performing backups on Fridays) it would mean a lost week of data. A backup was not performed this Friday as I was down to 1xHDD in the RAID and wanted to have a mirror first.

I will reconnect the drive and get the SMART message log from mhdd to see if that gives any useful information.

I would consider paying for recovery, but it would depend on how busy work is this week (busy = more money and less time to redo the weeks worth of work) and recovery cost. ie PCB replacement vs head replacement (WD drive seems to cost more than Seagate for whatever reason).

Can't hurt to ask here as the guru's likely have a much better idea of the issue and cost before sending it away to do diagnostics etc...

Info

You have many reallocated sectors, which means you have a lot of bad sectors on your drive.
Make an image of your drive, if its still possible and work with that image.

_________________
www.datarecoveryne.com

ISTM that the drive is reporting a temperature of -1C.

IIUC, a normalised value of 100 equates to 50C, and 93 represents 57C.

ie raw value = 150 - normalised value

Seems a bit low, but might be right.

Computer was shut off, heat wasn't on (anymore) and had a freak May snowstorm. I powered it up to grab the smart values. Didn't want it on any longer than it had to, since I don't know what is wrong with it.

I read the wiki and hddguru FAQ, and thought the number reported in "RAW" was the number of sectors reallocated?

The number of reallocated sectors is indeed zero. However SMART is reporting 748 pending sectors, and 191 reallocation events.

This means that your drive has recorded numerous read errors. Many sectors have so far been returned to service after retesting, but 748 remain as pending. They will be retested the next time the OS writes to them.

Thanks for clarifying about the reallocated sectors.

If this helps determine the cause, if the HDD remains off for a while (say 12 hrs) it will start booting into the OS, but crash after ~2 min. In any subsequent attempts the HDD doesn't even appear in the BIOS listing until it is left to cool down again.

I haven't fully rebuilt the OS (Gentoo) and restored the backup of the /home partition, but figure that I can put the failed drive into a hotplug caddy and grab the files that didn't make it to the backup...2 min at a time once the new drive is bootable.

Leaving the hard drive alone for now tho'. Not sure how many more 2 min read cycles are left.

I let it sit for almost a month then booted it up prior to junking it...guess what, it worked. So I put a hard drive water cooler on it and let ddrescue run. No idea why it would only run for ~1 min before stopping a month ago, but all it took was one last time and I got an image.

First pass: ddrescue --no-split /dev/sdb ~/wd ~/wdlog
Second pass: ddrescue --direct --max-retries=3 /dev/sdb ~/wd ~/wdlog
Third pass: ddrescue --direct --retrim --max-retries=3 /dev/sdb ~/wd ~/wdlog

Restored onto another 500GB drive with: dd /mnt/drive/wd /dev/sdb

The final ddrescue log file

Congratulations.

It appears that your log is showing 4 bad sectors around the 32GB point.

0x7A5C5DC00 = LBA 0x3D2E2EE
0x7A6086800 = LBA 0x3D30434
0x7A6086E00 = LBA 0x3D30437
0x7A608B600 = LBA 0x3D3045B

This article may help you determine which file occupies a particular sector:

Bad block HOWTO for smartmontools:
http://smartmontools.sourceforge.net/badblockhowto.html

BTW, I realise that temperature sensors are not accurate, but your SMART report would suggest that your drive's heads were flying at subzero temperatures, in the absence of frost or condensation.

It may be interesting to retrieve the drive's temperature history.

The smartmontools forum informs me that the following command will retrieve the historical temperature data for a supported HD:

smartctl -l scttemp /dev/ice

Other useful options are "-l scttempsts" and "-l scttemphist".