Seagate SATA ddrescue - zero bytes rescued

[Gray]

Hi

- Seagate Momentus 5400.6, 500GB, 5400rpm Harddrive
- From IOMEGA USB External Drive Enclosure
- MacBook Mac OS X Version 10.5.8

The above drive died a few months ago whilst plugged in overnight. I retrieved the HDD from the enclosure and noticed one of the diodes on the PCB was burned out (voltage fuse?). The HDD would not even spin up.

After a search Sherlock Holmes would have been proud of I managed to acquire a same-revision PCB. Swapped BIOS chip from original to donor PCB and the HDD happily spinned away. Drive now mounted in a WNSTARS SATA/USB drive enclosure connected to my laptop.

Fired up SystemRescueCD in the hope I could ddrescue, fsck, testdisk, photorec etc the drive but having no joy. My attempts at ddrescue run for hours but 0B are rescued. I don't need the drive working again but want to recover files/photos.

Below is some of the trail:

1. SystemRescueCD filesystems output. linux seems to understand the drive?
sda - local laptop windows xp
sdb - usb attached spare 300GB 'outfile' target drive for ddrescue
sdc - my 'failed' macbook sata drive

=====================>>> fsarchiver probe simple <<<=====================
[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[sda ] [FUJITSU MHW2100B ] [ 93.16 GB] [ 8] [ 0]
[sdb ] [External Drive ] [ 298.09 GB] [ 8] [ 16]
[sdc ] [5AS ] [ 465.76 GB] [ 8] [ 32]

[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN]
[loop0 ] [squashfs ] [<unknown> ] [ 288.07 MB] [ 7] [ 0]
[sda1 ] [ntfs ] [<unknown> ] [ 90.43 GB] [ 8] [ 1]
[sda2 ] [vfat ] [<unknown> ] [ 2.73 GB] [ 8] [ 2]
[sdb1 ] [ext3 ] [<unknown> ] [ 298.09 GB] [ 8] [ 17]
[sdc1 ] [<unknown> ] [<unknown> ] [ 31.50 KB] [ 8] [ 33]
[sdc2 ] [<unknown> ] [<unknown> ] [ 28.00 KB] [ 8] [ 34]
[sdc3 ] [<unknown> ] [<unknown> ] [ 28.00 KB] [ 8] [ 35]
[sdc4 ] [<unknown> ] [<unknown> ] [ 28.00 KB] [ 8] [ 36]
[sdc5 ] [<unknown> ] [<unknown> ] [ 28.00 KB] [ 8] [ 37]
[sdc6 ] [<unknown> ] [<unknown> ] [ 256.00 KB] [ 8] [ 38]
[sdc7 ] [<unknown> ] [<unknown> ] [ 256.00 KB] [ 8] [ 39]
[sdc8 ] [<unknown> ] [<unknown> ] [ 256.00 KB] [ 8] [ 40]
[sdc9 ] [<unknown> ] [<unknown> ] [ 128.00 MB] [ 8] [ 41]
[sdc10 ] [<unknown> ] [<unknown> ] [ 465.64 GB] [ 8] [ 42]
[sdc11 ] [<unknown> ] [<unknown> ] [ 8.00 KB] [ 8] [ 43]

Press a key to continue
=====================

2. Output from cat/partitions.
root@sysresccd /mnt/seagate % cat /proc/partitions
major minor #blocks name

7 0 294980 loop0
8 0 97685784 sda
8 1 94823631 sda1
8 2 2859570 sda2
8 16 312571224 sdb
8 17 312568641 sdb1
8 32 488386584 sdc
8 33 31 sdc1
8 34 28 sdc2
8 35 28 sdc3
8 36 28 sdc4
8 37 28 sdc5
8 38 256 sdc6
8 39 256 sdc7
8 40 256 sdc8
8 41 131072 sdc9
8 42 488254592 sdc10
8 43 8 sdc11

=====================

3. Attempt to mount sdc
root@sysresccd /mnt/seagate % mount -t hfsplus /dev/sdc /mnt/bernshdd
mount: wrong fs type, bad option, bad superblock on /dev/sdc,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

root@sysresccd /mnt/seagate %

=====================

3. Attachment - Dmesg output when sdc is switched on


4. Attachment - ddrescue log


Any idea where I might go from here please?

Attachments

ddlog.txt

(26.87 KiB) Downloaded 642 times

dmesg.txt

(122.66 KiB) Downloaded 647 times

[drc]

Few things:
You're trying to mount the whole drive instead of just /dev/sdc10

dmesg log shows bad sectors

At this point it could just be some bad sectors, or it could be one or more whole bad heads, or it could be the Seagate issue where some bad sectors cause it to return all ABRT errors until it is repowered

In any case, if you're not able to image using ddrescue or similar, you should have a pro (such as pcimage) look at it.

[Vulcan]

@Gray:

I agree completely with the reply from drc. Here are a couple more comments:

The behaviour of the drive (no readable blocks as shown in the ddrescue log) is not what would be expected if the problem was limited to a PCB which you then correctly replaced. Therefore the initial problem is likely mis-diagnosed e.g. PCB problem was a symptom but not the cause, or another undiagnosed problem still exists, or PCB replacement was not done correctly, or other component(s) were damaged in the PCB replacement process etc. We're unlikely to be able to identify which of those situations exists remotely... Therefore if the data is valuable, you may want to reconsider your decision to do DIY and instead ask a trusted DR company (like pcimage on this forum) to work on your drive - hoping that the drive is not already unrecoverable.

I have found that in the more difficult cases, ddrescue needs to be used interactively by an experienced user, reacting to what behaviour is seen and changing ddrescue options or other actions as appropriate for that disk behaviour - it is not a "one click" solution in every case, though some tutorials may wrongly imply that. IMHO the command line you are running would only be appropriate for a disk which was mostly readable with a few limited areas of unreadable blocks. It is just wasting time doing retries on a disk behaving as yours is doing.

It's odd that Linux seems to identify 11 partitions on that disk (sdc1 - sdc11). Look at the sizes of those reported partitions; most are unreasonably small. Therefore this does not seem to be valid recognition of the actual partitions. Looking at the dmesg immediately after boot (not the example you kindly attached to the first post) may give you some clues about what happened at that point.

Using a USB connection for your "problem" drive (as you describe for your /dev/sdc) is not optimal, as it introduces problems with potential mis-reporting of errors and other idiosyncrasies and limitations of the USB-SATA bridge and with error recovery. Therefore I would always use a direct connection for the "problem disk" with ddrescue. A USB connection for the disk holding the output of the clone is OK, since you don't expect errors to occur on that.

Finally, your "problem disk" (/dev/sdc) appears to be 465.76 GB. Your "clone output disk" (/dev/sdb holding a filesystem mounted on /dev/sdb1 I think) appears to be 298.09 GB - and you appear not to be using any compression on the clone output (not that I would recommend doing that anyway). The expression "trying to squeeze a quart into a pint pot" springs to mind! So you need to re-think your recovery setup in more than one way IMHO, if you are intent on doing DIY.

Any idea where I might go from here please?

Use the services of a DR company, if the data has value?

[Gray]

Ok Gents, thanks for your input..

In terms of outfile drive smaller than infile; I thought once I'd got a > 0B rescued I'd limit the size.

In any event, I had a sneaking suspicion it was going to be more complicated than I thought. I might try plugging the HDD diresctly into a spare laptop.. if that does not wotk then it looks like I'm shelling out a few £££s...

Thanks again
Rgds

[Gray]

Actually... I should have asked.... do you think I should put this drive into my laptop? I started to wonder about voltages and whether I might end up with a dead laptop as well as a dead drive ?

Thanks

[Vulcan]

I started to wonder about voltages and whether I might end up with a dead laptop as well as a dead drive ?

Welcome to the risks of DIY

There are risks with anything that you do - you may also damage the drive even more during moving it from the "new" USB enclosure, either due to a slip with a screwdriver, or damage due to static discharge (ESD), or other things...

Based on your report that the drive is spinning in the USB enclosure, I think it is unlikely that it would cause damage to a laptop with the correct interface, that it was (correctly) plugged into, using good ESD precautions, with the power off and battery (temporarily) removed - but as always, that comment cannot be a guarantee. Part of the benefit of paying someone else, is for removing this kind of hassle & uncertainty, as they are using their equipment and not yours.

Your data; your risk; your choice. If you don't feel comfortable / able / confident doing something, then don't do it.

[drc]

It's odd that Linux seems to identify 11 partitions on that disk (sdc1 - sdc11). Look at the sizes of those reported partitions; most are unreasonably small.

This is normal for Mac drives if they have been partitioned with OS9 support

[Gray]

Hi

Thanks for the advice gents... I think I was getting over-confident... I've managed to recover several disks in the past.... probably more luck than judgement!

I wonder if those small partitions were to do with journalling? ... I've seen one or two threads suggesting mac-journalling needs to be switched off before write access is used... I kinda' ignored that because, as far as I know, ddrescue, testdisk, photorec etc only read; certainly I did not want to hook it back in the mac to do so because I feared an electrical fault.

Cheers

[Vulcan]

@Gray,

I don't work with Mac systems in my (non-DR) job, so that latest Mac-related info from drc is helpful (thanks, drc) and answers a nagging doubt in the back of my mind about another part of the data shown.

There are no guarantees of correct remote diagnosis by me, but with that partition info, and with the info that you supplied, this behaviour fits one of drc's earlier comments especially well IMHO. That is a type of drive problem where other users have reported good success when they took the drive to a DR company who had a disk imager called a DDI (Deepspar Disk Imager). If that is all that is needed to recover the data, then a reputable DR company would not charge you an arm and a leg.

However, my experience with drives having that specific behaviour has been that the drive degrades in its ability to read the media, the more the drive is used. Therefore all of the previous warnings about the potential consequences of DIY do apply. For that reason, if you're going to use the services of a DR company, I suggest to stop DIY now and hope that the drive's problem has not already gone beyond relatively simple recovery (with the right equipment!).

Good luck!