Hey, I would be careful about swapping controller boards. It's been a few years since I spent any time working against bare metal drives but the controller used to have sector remapping info stored on eeprom. If that info has moved to the platters then you should be good, otherwise you may find some weird errors as the two drives are *very* unlikely to have the same set of bad sectors mapped the same way (the same sectors would have to fail in the same order).
If you can find a way of copying just the eeprom sector remapping data from the failed controller to the good one, then you may be OK. If this is a case of better some data than nothing then you may as well go ahead and try. This sounds a lot like the bullet I dodged about a year ago. I'm still very annoyed with Seagate because it cost me close to $400.00. That problem manifested when a failure occurred after exactly 'n' power cycles. My, admittedly brute force, solution was to buy a 2nd NAS and copy all the info off the old NAS (with Seagate drives) onto the new one (with Samsung drives). I consider myself lucky - everything was on UPS so I didn't risk triggering on power cycles. Slow & expensive but low risk. I think it's time for your friend to spend a few minutes thinking about the value of the data. If it's worth it, send it to a recovery op - look for special pricing because Seagate did a deal last year with one outfit and recovery was flat-rate US$75.00 for my problem. If the data is just nice to have then he can try the recovery himself as a hobby. Or he can ask around for someone to help him - might cost him a bottle of Scotch though. On Tue, 2010-02-16 at 01:04 -0700, Gustin Johnson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > TekBudda wrote: > > A friend of mine is suffering from the following problem: > > * http://sites.google.com/site/seagatefix/ > > > > He has ordered the part, but cannot get the data off because they will > > only do it in the states. Unfortunately he doesnt have a abckup...as > > a matter of fact he was going to back it up when this happened. > > > > The only things I could suggest were to try & boot from a live cd & > > see if it can be detected at all through proc or whatever & then dd > > the data off. I also suggested that he could tr and install it in an > > older computer. > > > Not going to help. The problem is with the drive not the OS. > > Either he needs to convince someone to help him perform the tutorials > that you posted (both were different people doing the exact same fix) if > he can't do that himself. > > Plan "B" might be to take the PCB from a good drive (the same make and > model) and replace it with the one on the bad one. > > Plan "C" is to send to the expensive data recovery people. By expensive > I mean thousands of dollars. Spinrite is not going to help here. > > Otherwise he is up the creek. > > > This apparently shows how to solve the problem: > > * http://www.youtube.com/watch?v=29FztWJVxbM > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkt6UZsACgkQwRXgH3rKGfNOZwCeOez6B6G4Cb3zFBx+B5RpWIIG > takAn1hqLS3mJcRJnz034ZpIppGmE2Li > =1Rbx > -----END PGP SIGNATURE----- > > _______________________________________________ > clug-talk mailing list > [email protected] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
