@smportis,

Many thanks for those photos.

FYI, the BIOS "disk setup screen" (I should have been clearer about what I wanted) is something different to what you showed - on your Award BIOS, you'd need to hit Del to enter the setup, and somewhere after that, you'll have an option for disk setup (which is where I guess you saw the 1GB value before?). However, I think that point is now "moot" due to the correct capacity & model number shown by SeaTools.

So, given the correct drive make, model & capacity shown by SeaTools for DOS then, as pcimage & mr_spokk both said previously, and given that you have accepted the risks of DIY, I would choose a non-Windows cloning utility. Now this is where it gets more challenging for you. There is no "press button for perfect results every time" cloning utility, and when I'm cloning failing disks (as part of my non-DR job), I sometimes have to interrupt the process and choose different cloning parameters, depending on exactly how that specific drive is behaving. In other words, it can need an interactive approach to maximise the chances of success, which is impossible to perform sensibly via a web forum, so all I can do is give a few summary points, all IMHO of course. I'm not promising further replies - much has already been written (by me and others) about cloning, if you search the forum:

- You have a choice of cloning utilities depending on your budget, skills, expectations of support, patience etc. As a "free" option, personally I use GNU ddrescue (different from dd_rescue) - I have never tried Media Tools Pro. For all I know it might be better (but needs to be purchased).

- I suggest that you get a different working disk which you don't mind losing / erasing (e.g. in the event of human error) and practice using a few different cloning utilities to clone that disk onto whatever new disk you say you've bought to hold the result (target) of your clone. Only move on to try cloning the now-quite-dead disk, when you are completely confident that you have practiced enough using your choice of cloning utility.

- Just to be clear, the disk you are cloning should be attached via SATA - it is rarely a good plan to attach a failing disk via USB, for cloning. (I know you didn't say you'd do this - I mention it just in case that was part of your plan).

- IMHO it's usually preferable in this type of situation, to do a raw clone from disk to disk, rather than clone into a file, unless you have specific reasons to do the opposite.

- There can also be advantages to getting yet another new disk, to allow for some later recovery attempts, depending on how successful the first cloning attempt is. For now, just be aware, do not do anything (e.g. including running chkdsk / fsck) on the result of your clone (i.e. the new disk). It should only hold the unchanged copy of the original disk.

- Overall, I would attempt to clone as much of the failing disk as possible, with zero retries and a large copy size (sometimes called block size). Then have the cloning utility go back to any unreadable blocks and apply increasing levels of retry, try reverse the direction of copy, smaller block size etc. etc. That approach tries to perform the "easy" parts of the clone first, so that if the failing disk does die catastrophically part way through, you have a chance to get something from it first, rather than spending lots of time on any "difficult areas" and potentially clone less in total from the disk, before it dies.

To address the comment from einstein9 - if your specific Netgear NAS RAID level needs clones of both disks before you can recover data, then cloning this one disk (even if successful) is only part of the process, and you'll still need professional help with the other disk. I thought you said Netgear only needed a clone of one disk, which is why I invested this time in the thread, so I'm confused about the real situation...

As always, there are many different approaches & opinions, and giving advice remotely, when we can't see the details of the cloning as it progresses, means that there are always alternative options which can't sensibly be described without writing a book! Hope the above gives you some ideas, but it has to be your decision whether to proceed or not. Good luck!

[Edited for spelling mistakes & clarity.]

Hmm, now it shows right model in Bios and size...I recommend you to clone that drive asap...mediatools or other imager.

Bosse

_________________
Rescue IT Datarecovery service Sweden
Rescue IT Dataräddning Göteborg AB
http://www.rescue-it.se

Yes, great MOBO the ASUS. Built the PC a while back (obviously).

I can get the RAID rebuilt by the support guys at Netgear if I can get either one of the 2 drives running (it had 4 drives in it, only need 3).

Power issue? I assume you are not asking me, but the experts on the board....

Thanks for the input! Love forums where people are willing to give their time. The human race may not be doomed after all.

When I talk about diagnostic interface, it looks like this:
http://www.hddguru.com/articles/2005.10.01-Seagate-RS-232-adapter-schematic/
Pro's call it "professional tools". But you perhaps have heard about it, as you know about freezer method.
Glad to see yor drive is recognised correctly, clone it A.S.A.P.
If you have problem with cloning, the other (dead) drive might be easier to clone, but you must repair firmware first from diagnostic interface, using LVTTL converter like the one above.

Vulcan et al.,
Thanks a ton for the guidance, time, and patience. I'll make good use of the search function for other disk recovery guidance. I'm a fairly hands on computer engineer (by education and prior experience), just not with HD recovery. I ain't afeared as my kindred say down here in the south, so I'll give it a try.

I'm resolved that I've lost these pictures (the 4 months worth), but am willing to try to recover them vs paying the high price for them to be professionally recovered, given the remote chance that even once recovered, we still have to rely on Netgear engineers to recover their proprietary XRAID configuration. If it were ALL the pictures, money would be no object.

To be brief, as my above comment noted, yes, the goal is to get 1 of the 2 dead disks "cloned" and then put it in the raid with the 2 other good disks (for a 3 disk recovery set) and let the Netgear engineer ply his magic remotely. With some errors, and the data striped across the 3 disks, there is a pretty high chance that I will get most of the data back from the dead (at least that's what I keep telling myself. LOL at my own optimism).

So, ddrescue, not dd_rescue. I just checked and Knoppix 7.04 has ddrescue 1.23 on it, so I have the correct one on CD ready to go.

Thanks SAjunky, I'll check it out.

You're welcome Thanks for explaining more of your background, the explanation of why cloning either of the 2 failed drives is enough, and the reasoning for trying DIY.


a) Just to be clear, I didn't say GNU ddrescue was "correct"; it's just the one that I chose, after doing an assessment of the available utilities, some time ago. Other people use & recommend dd_rescue (often in combination with dd_rhelp). It's up to you to decide which you prefer.

b) Unfortunately you've made a (very very) common mistake, because of the massive confusion between "GNU ddrescue" and "dd_rescue", due to the naming that is used in some Linux distros. It's impossible that you have GNU ddrescue v1.23 - that version doesn't exist. Version 1.16 is the current latest:

http://ftpmirror.gnu.org/ddrescue/

Have a read of this page, where they recommend (and give some useful general techniques for using) GNU ddrescue, but remember they are not necessarily optimal for your specific case. Unfortunately their examples use files for the target of the clone (as I said before, that is typically not what I recommend for people inexperienced in these techniques - it adds some flexibility and further options (e.g. like compression), but adds some complexity too):

http://www.forensicswiki.org/wiki/Ddrescue


Also note that using a GNU ddrescue log file, on a mounted filesystem (e.g. USB stick, if you're booting Knoppix from CD/DVD) is vital, to get the maximum benefits e.g. be able to review which blocks were readable, and be able to restart cloning without repeating parts of the clone which were previously successful.

I hope that helps clarify the confusion about dd_rescue vs. GNU ddrescue.

Yes, ok, no, not familiar. You are saying to use a tool that is built from a breadboard, and some capacitors, diodes and resistors. Don't know what the 78L05 is but I get the idea. Being my first harddrive to try to beat back into existence (is it 4 breaths and 2 pumps, or 2 breaths and 4 pumps?), I've not delved that deep.

Deleted by OP

I did read that dd_rescue was poorly executed and had to have dd_rhelp wrapped around it to make it functional, and that ddrescue was much better.



Ok, good catch.



When using ddrescue with a mem stick, will it write the log file to the root of where it is running from, or will I need to pipe it somewhere? Its been a long time since any unix experience, and I've not used it that much.

Thanks again - getting me closer to regaining trust from my wife!

Unix newbie question - Can I "make" and "compile" the ddrescue on the memory stick if I'm booting from the Knoppix 7.04 CD? I guess the Knoppix CD will have make & compile on it? Can I compile it on a mac and just save it to the memory stick, and then run it under knoppix? Should I set the memory stick to boot knoppix and put the proper ddrescue version on there, and then compile it?

Probably stupid questions, but coming from the precompiled Win world, I know you understand why I'd need to ask this.

Thanks all.

--
Hey Look, I can add a sig now.... Nah.

Yes, exactly breadboard. I actually do not use 78L05, to generate 5V for MAX232 for two reasons:
1. If terminal program do not set DTR/RTS there is no power to MAX232. Example: ST_MEM
2. I connect power to hard drive from exernal power supply, so I can cycle power when I need it. I take 5V from here.
There are RS232 to LVTTL converters on ebay for $5-15, also USB to LVTTL converters for $10-20, later one emulate COM port in driver stack.

Bump on this question.

@smportis,

[Edit: I was already part way through writing this reply when you bumped your question. Your expectations about a speed of response are unrealistic, if you are already bumping a question which is, actually, off-topic here, and is also less than 24 hours old. I'll be travelling on business soon, so may not be viewing the forum for multiple days at a time to even see any new questions, let alone reply to them. If you don't have much Linux sys admin experience, then please reconsider whether you want to go ahead with using ddrescue. This forum is not a source of Linux support, OK? ]

I don't have time for a long reply, but I'll try to briefly answer your recent questions:


It will write the log file to the current working directory, unless you specify a different directory on the command line. Where the ddrescue instructions say "logfile" as a command line option, you can specify a directory too e.g. /media/sdz/nearly-dead-drive-logfile if you want the log file to go somewhere other than the current working directory. There are many possible approaches; different people have different preferences.

One simple approach is this: Put the compiled ddrescue executable onto a formatted USB stick; mount the filesystem on that USB stick "read/write" (not read-only) using whatever mount point is appropriate for that Linux distro e.g. /media/sdz or whatever (some distros will do this automatically); cd to that mount point; execute ddrescue from there; and because you are running ddrescue after doing that "cd" command, then that mounted USB stick filesystem is the current working directory and hence it's the default destination for [whatever name you give to] the log file.


If you decide to continue with a *nix approach, my previous recommendations to practice with a different source disk drive (and read online tutorials, and especially read the ddrescue manual page with its examples & explanations) definitely apply. If you get this cloning process wrong, you can easily overwrite your nearly-dead drive, in such a way that no-one will ever recover the data e.g. if you reverse source & target of the clone process.


As a brief answer (since Linux support is off-topic for this forum) - I've never tried that specific Knoppix version, but previous versions included gcc, which is what you need, and they would allow you to compile ddrescue. See this webpage (near the bottom) for simple instructions on compiling ddrescue:

http://www.cgsecurity.org/wiki/Damaged_Hard_Disk#The_best_method:_Antonio_Diaz.27s_GNU_.27ddrescue.27

Or there are other Linux live-CD distros which claim to already include GNU ddrescue, though not necessarily the latest version.

Hope that info helps

Sorry Vulcan, I did not mean to be greedy, or to disrespect your time (or anyone else on the forum that might have responded). I was simply making sure that since it was not the last post, it was visible to the casual observer who might have jumped into the thread. I truly appreciate all the free time being given to me by all of you on this. I'm trying to be very respectful.

I understand that it is off topic, and I hoped that the answer was quick enough and the context understood by the readers to be given a bit of leeway (which you have).


That all help tremendously! I guess I just wish someone could hold my little hand but I have to forge onward. I don't want to make a fatal error here doing something stupid, so I'm trying to learn all I can before this ticking time bomb goes off.

Just an update for everyone:
Ok, I ran the bad disk that was only reporting 16GB first, hoping that ddrescue would get the entire disk, but it indeed stopped at 16GB. No errors reported or logged.

I did: ddrescue -f /dev/sda /dev/sdc log.log

Researching ways to force it beyond what it thinks is the disk capacity....

Ok, so using ddrescue -s option to try to force it to read beyond the 16GB that it thinks are there (750GB drive), doesn't work.

Anyone know of a way, or another tool, to read past what the file system thinks is there?

(Running Knoppix 7.04 from CD)

Thanks,

Scott

Now running ddrescue on the less damaged drive. Entire drive is seen by the unix os, but when I run ddrescue, it fails to find a single block of good data:

ddrescue -f -n -v /media/sda /media/sdb logfile
ddrescue -f -d -v /media/sda /media/sdb logfile

Rescued: 0 B, errsize: 750 GB


Diagnosis? Is it possible that every block is bad, or is this a read head error, or something else?

Should I try another method or tool?

Thanks,
smp

Do you actually believe that Open Src freeware can fix this?
heheh
carry on, and good luck with it

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

@smportis,

If the "16GB" drive is the one which you earlier said was clicking and not recognised by SeaTools, then I've already given my view on that. More investigation could be done (with associated risks), but based on the symptoms you describe, such investigation is likely to be a waste of time for DIY due to the very likely diagnostic result IMHO.

Regarding the not-quite-dead drive which still reports 750GB, the ddrescue commands in your latest comment are wrong. The ddrescue infile and outfile parameters should be /dev[/something] devices (you must be sure that you use the correct device names - this is vital!), and not /media[/something] mounted filesystems.

This attempt may still be unsuccessful, as there is a specific failure mode of recent Seagate drives (esp 7200.11 & .12) - we won't know unless you try ddrescue (correctly). However I have not yet seen a successful DIY recovery of a drive with that behaviour. On the other hand, drives with that behaviour have been recovered using a hardware imager (specifically Deepspar), which could be done at a suitable DR company. IMHO, for a DIY result, all you can hope for is that the drive has not yet deteriorated to that level.