need help to recover RAID0 drives

[jono-ats]

Maybe you can explain to me how this is going to help the OP when the other drive of a RAID 0 has "failed completely?"

Read it again ... slowly this time.

I did. It made no more sense to me. The OP said his RAID 0 drives are Seagate 3 TB in the first post. So what does the pending sectors of a WD drive have to do with the risk to his Seagate drives?

Maybe you should read my post again, too -- because you have not answered the question I posed to you:

Maybe you can explain to me how this is going to help the OP when the other drive of a RAID 0 has "failed completely?"

[fzabkar]

I have 2 Seagate cuda’s 300GB’s running RAID0 (sorry about that).

The OP clearly understands that RAID 0 is not a backup.

The WD drives are externals. External drives are most commonly used as backups. Ergo my warning to the OP.

----------------------------------------------------------------------------
(4) WDC WD20EARS-00MVWB0
----------------------------------------------------------------------------
Enclosure : WD My Book 1130 USB Device (V=1058, P=1130, sa1) - wd
Model : WDC WD20EARS-00MVWB0

(5) WDC WD1600BEVS-00RST0
----------------------------------------------------------------------------
Enclosure : WD 1600BEV External USB Device (V=1058, P=0702, sa1) - wd
Model : WDC WD1600BEVS-00RST0

[jono-ats]

We must be speaking different languages. The OP initially wrote:

"I can’t find anyone who can help me with my RAID0 problem. Here is my problem,. I have 2 Seagate cuda’s 300GB’s running RAID0 (sorry about that). I was not able to get any of my files so I gave my drives to one (PRO). After about a week he told me that my first drive is dying and the end of the week died completely."

You told him to clone the remaining RAID0 drive. I suggested that he not.

He wants to get his data back. From the Seagate RAID0.

I'm obviously confused. It doesn't matter.

[fzabkar]

We are all aware that there is no redundancy in RAID 0. The "good" Seagate drive has a few Uncorrectable and Pending sectors, plus it has a poor Seek Error Rate attribute. It would be advisable to clone it, whether or not it had these anomalies. The next step, for a DIY-er, would be to repair the bad drive and then clone it, too.

According to data-medics (a "pro") ...

"The fact that the drive is able to read ID for the SMART report but didn't actually read any SMART info pretty much confirms that the issue is either the media cache or bad sector re-allocation firmware bug."

... to which I responded ...

"@fandi1, if the problem is confined to media cache and/or firmware bug, then there is potentially a simple DIY solution. To this end you would need a TTL adapter to access the drive's terminal log."

A "pro" would edit and rewrite sys file 93 using PC$10K (that's what data-medics keeps telling us), but a DIY-er can achieve the same end with a US$5 TTL adapter and a freeware terminal program. In fact I have written a ZOC script which reduces this to a point-and-click procedure (see the HDD Oracle thread).

[jono-ats]

Fzabkar: I recognize that we approach things from opposite sides of the spectrum. I am most concerned with using best practices to maximize the chances for a successful recovery; you are for spending a minimal amount of money and taking more risks. Each has its place depending upon circumstances, but there are plenty times when saving data is more important than not spending money.

A couple of things strike me offhand. These concerns come from opening thousands of drives in a clean room to perform failure analysis.

The first is when a drive degrades in performance to a point where it can't be read, it can certainly be caused by firmware corruption. But the most common cause for cascading corruption is bad or dirty head(s). It reports the wrong size and has other issues, but apparently does not spin down, so catastrophic failure likely hasn't occurred YET.

This is my opinion, but compared with other heads, Seagate's seem particularly prone to catastrophic failure once they become contaminated. It may have to do with flying height adjustments, but the bottom line is that major failure can come without notice and preclude recovering anything. In other words, if there is likelihood of head degradation, that problem needs to be addressed before it causes media degradation. Running a Grenada series drive in this condition is, in my experience, quite risky.

The second "red flag" is that any pro worth their salt ought to be able to fix firmware issues that are noted in this thread --- and others. So either they don't know how to do this; weren't successful in trying; or maybe the problem isn't "just" firmware.

In EVERY case where data is important, thorough and competent diagnosis is needed BEFORE any interventions are attempted.