Seagate ST31000340AS bsy fix then possible head crash?

[TommyTuffNutz]

Drive: Seagate ST31000340AS, 1Tb, Came from an HP system, 2 partitions: 1 HP partition and the other the main partition

I have done a couple BSY fixes on Seagates for friends and family without problems, but this drive (my fathers) is acting a little strange after BSY fix.

After the fix I plugged it in internally on my PC. It took a while for it to come up and when it did only the HP partition loaded. The main partition came up as local drive and wanted me to format it. This is not good.

So I tried cloning it using ddrescue. It was cloning fine and then gave errors and 700Gb didn't clone. I suspect read head failure or corrupt sectors??

My questions...

1. If it a read head then I assume there is no good free software to image this correct? I've been reading and RawCopy came up as a better choice than ddrescue in a this situation. Tools like PC-3000 or DDI would probably be what DR companies would use on this first correct?

2. When I performed the clone using ddrescue I basically just typed

Code:

ddrescue /dev/old_disk /dev/new_disk log.txt

So my second question is: is it better to make an image instead of cloning the drive? Like...

Code:

ddrescue /dev/old_disk /dev/new_disk/recovery.img log.txt

This would require the destination drive to be formatted and partitioned correct?

Thanks

[harddrivespecialist]

In a lot of cases, "busy" problem occurs due to a large number of bad sectors on a drive or possible problems with one read/write head.

You are correct, Professional tools usually do a better job.

Destination drive should always be wiped off any data.

[northwind]

Is the firmware of this drive HP24?

We won't be able to tell if heads crashed on this, if you don't give more info.
What's the terminal showing? You must have the proper equipment to get a terminal output (since you said you have corrected the bsy error in past). Does it click?

Regarding your other question about ddrescue, it is not my strongest point, so i'll let other advice you here.

[TommyTuffNutz]

Thanks for the replies.

Yes, firmware HP24. Do different firmwares have a tendency for head failures?

The busy fix went as normal...nothing unusual in terminal. No clicking.

Is there a terminal command you'd like me to try?

[loki]

A quick search on google for HP24 firmware bsy bug found this:

http://h30434.www3.hp.com/t5/TouchSmart ... td-p/32984

Might be worth searching HP24 bsy

Loki

[loki]

Would the HP26 Firmware work for the HP24 bsy?

http://h20000.www2.hp.com/bizsupport/Te ... Id=3733137


If anyone has a HP24 bsy drive they want to send me so I can test

Loki

[TommyTuffNutz]

I did see the update, but did not want to take a chance since the drive somewhat works.

From what I understand updating the firmware prevents the busy error from happening again.

This problems sounds like corrupt sectors/file system or failing read head. If updating might remedy this then I will try it.

[loki]

I also noticed that on the first link last post they used a donor drive to connect the original PCB to & then ran the firmware uppdate & then transferred the original pcb back to the original drive. Hope that makes sense

Loki

I just need to test it sometime when I can get one that has the same fault.

[Vulcan]

@TommyTuffNutz:

I have done a couple BSY fixes on Seagates for friends and family without problems, but this drive (my fathers) is acting a little strange after BSY fix.

This suggests that the underlying cause may have been different, or that there was more than one. There are multiple possible causes for that BSY symptom - the "internet fix" is designed for one of them.

Anyway, you're already getting advice on that part of your problem - I'll just reply about the use of ddrescue:

I've been reading and RawCopy came up as a better choice than ddrescue in a this situation.

If you're continuing to take the (many) risks of DIY recovery attempts, and have the storage space to hold another clone to avoid overwriting the partial one which you currently have, then trying RawCopy is another thing you could do. Based on your description, personally I doubt it will give a different result. If you have some website links to situations where RawCopy (I'm assuming you're referring to the Roadkil utility with that name) was more successful than ddrescue, that would be interesting.

However, remember that ddrescue is very configurable (RTFM ) and so you control most of its behaviour, unlike RawCopy. I can easily think of ways that ddrescue could be used which would be relatively unsuccessful, as well as ways in which it would definitely be more successful that RawCopy, all depending on the behaviour of the faulty source disk and how ddrescue is configured by the user for that specific behaviour.

is it better to make an image instead of cloning the drive?

Although I wouldn't use either of your specific ddrescue command lines myself, the answer to your question is "it depends on what you mean by better". Assuming that you have enough space on /dev/new_disk (in your example), then neither option will be more successful (better) reading from /dev/old_disk.

Writing to a file on the destination adds a little complexity to the sys admin which is needed (e.g. you need a mounted filesystem), and introduces extra processing & I/O overhead. But if you have only filesystem space and no raw disk space, then of course writing to a destination file becomes your only option. If you are using a compressed destination filesystem, then that may be useful in some situation (e.g. if free space is at a premium). You can also write to a destination file using NFS, if your destination filesystem is mounted on a different system, whereas writing to a raw disk attached to another system is a little more complex (e.g. using iSCSI).

Many options are possible (as with most things in the world of Linux/Unix) - which of them is better depends on your exact hardware configuration, sys admin skills, available disk space etc., as well as what you are specifically meaning by "better". However as I said above, neither of those 2 options would be more successful than the other in reading from /dev/old_disk, if that is what you meant.

[TommyTuffNutz]

Great stuff, thanks.

Although I wouldn't use either of your specific ddrescue command lines myself, the answer to your question is "it depends on what you mean by better". Assuming that you have enough space on /dev/new_disk (in your example), then neither option will be more successful (better) reading from /dev/old_disk.

So in my case when one partition came up as 'local disk' and was asked to format - what would you have done? Probably hook it up to a professional tool? What about in my case knowing I have none? I'm thinking the drive is failing so I tried to make a clone. What commands would you recommend?

Tesdisk website recommends this...

Code:

# first, grab most of the error-free areas in a hurry:
ddrescue -n /dev/old_disk /dev/new_disk rescued.log
# then try to recover as much of the dicy areas as possible:
ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log

Writing to a file on the destination adds a little complexity to the sys admin which is needed (e.g. you need a mounted filesystem), and introduces extra processing & I/O overhead. But if you have only filesystem space and no raw disk space, then of course writing to a destination file becomes your only option. If you are using a compressed destination filesystem, then that may be useful in some situation (e.g. if free space is at a premium). You can also write to a destination file using NFS, if your destination filesystem is mounted on a different system, whereas writing to a raw disk attached to another system is a little more complex (e.g. using iSCSI).

So if I understand this correctly it is always better to clone the entire disk to another disk (which was wiped) as opposed to writing an image to a partitioned drive? I did the former.

[Vulcan]

I don't have time to give another lengthy reply, and certainly not to do a step-by-step ddrescue tutorial for this situation. I only tried to help by answering your previous questions about ddrescue - knowing my other commitments, I didn't say I would be able to give further answers, so here are brief replies (all IMHO and based on my experiences, of course) to some of your additional questions. Further replies not guaranteed.

Tesdisk website recommends this...

Code:

# first, grab most of the error-free areas in a hurry:
ddrescue -n /dev/old_disk /dev/new_disk rescued.log
# then try to recover as much of the dicy areas as possible:
ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log

Yes, that's a starting point for a disk which may fail at any time, but is likely sub-optimal (e.g. for speed, and does not use any of the newer ddrescue options to optimise the first pass e.g. if the reads become slow), and further steps after those shown (or instead of those) may be needed, depending on how that disk behaves exactly.

It is also possible that there is nothing better you can do using any host-based software, with that disk in its current state. Welcome to the limitations of DIY recovery attempts, without having a professional diagnosis.

So if I understand this correctly it is always better to clone the entire disk to another disk (which was wiped) as opposed to writing an image to a partitioned drive?

No. I said there are circumstances when either can be appropriate, and there are advantages & disadvantages to each, but it still depends on what you mean exactly by "better", and you still haven't defined that.

Personally, I would be looking at the disk's terminal output at the time of the apparant read errors, to see what it is reporting - that's already been suggested to you...

[Vulcan]

For the benefit of other readers, this thread is also related:

ddrescue-error-writing-logfile-space-left-device-t21795.html

[TommyTuffNutz]

^^ your help is much appreciated.

Another question...

Is it possible to use Seagate terminal commands to diagnose a bad head?

Here is an article...

http://www.datarecoverytools.co.uk/2011/01/29/how-to-test-seagate-drives-heads-for-hdd-repair/

The safe mode commands R1 and R2 do not work. I get 'invalid diagnostic command' for those and some of the other commands.

I have not used MHDD yet, but from what I understand combining it with Seagate terminal commands one could diagnose a bad head. Is this true? Anyone care to share the technique? It would be nice to know for sure if I have a bad head.

EDIT: drive is now HP26 - still functions the same.

[TommyTuffNutz]

This is what I get in terminal...

Code:

F3 2>H0
Hd 0

F3 2>H1
Hd 1

F3 2>H2
Hd 2

F3 2>H3
Hd 3

F3 2>H4

Error 00FE DETSEC 00003000
F3 2>

As a test I tried H4 (head 5) even though it does not exist since the drive has 4 heads.

So all four heads respond, but I'm assuming it has nothing to do with their read/write capabilities??

If anyone can shed some light on this for me that would be wonderful - even a PM would work.

[hddguy]

That document and those terminal commands are for a totally different series of Seagate, prior to F3 which is your model.

The commands are pretty much the same (H command in both series is to select a specific head ) but sending commands from a totally different series can be irreversible and can lead to permanent data loss.

At this stage I would seriously suggest sending this to a professional before data recovery becomes impossible.

Next time you send a terminal command you do not understand you may not be so lucky with it

[TommyTuffNutz]

^^^I appreciate your concern, but I would like to pinpoint the problem at home with the help of this fine board. Data is not really important at this point.

So...can you point me in the right direction?

The big question I would LOVE some help with is: Can we narrow it down to a bad head with MHDD and Seagate terminal commands?

[BlackST]

The big question I would LOVE some help with is: Can we narrow it down to a bad head with MHDD and Seagate terminal commands?

NO.

And what's even worse, if head(s) is (are) not completely FUBAR it is still possible to get data out of the drive. But this is another story.

[TommyTuffNutz]

NO.

Dang it. I thought I was reading somewhere that using MHDD you can have a pretty good idea that you have a failed head. It will not tell you that directly, but somehow someway you can have a pretty good idea. Oh well.

And what's even worse, if head(s) is (are) not completely FUBAR it is still possible to get data out of the drive. But this is another story.

I realize this. An Atola Insight would be perfect for this situation.

[drc]

NO.

Dang it. I thought I was reading somewhere that using MHDD you can have a pretty good idea that you have a failed head. It will not tell you that directly, but somehow someway you can have a pretty good idea. Oh well.

I would say that, for a person who knows what he is looking at, it is definitely possible to interpret head(s) failure from certain behaviors of MHDD. Doesn't work for sure, or in all cases, or by someone who doesn't know what to look for or at, etc. I would guess that BlackST's "NO" comes more from keeping these qualifications in mind, rather than as a blanket statement that "No you can't ever know a drive has a bad head based on MHDD"