Hi Matt,
Your recovery process is obviously going rather slowly, but, take heart, sometimes the process speeds up after it gets past the worst error area. Unless there are only a few errors, the copy time is almost entirely proportional to the number of errors, because error-free sectors copy so quickly and bad sectors take so long to fail. (Unfortunately, I don't know of any way to stop the drive's very slow internal error recover process, for a quicker first pass.) Your strategy seems pretty good except for a couple of small mistakes. First, your recovery command should have been: ddrescue -B -n /dev/hda /dev/hdb rescued.log instead of ddrescue -B -n /dev/hda1 /dev/hdb rescued.log Unfortunately, the command you used will omit the MBR, so there'll be no partition table on /dev/hdb. Oops! I do NOT recommend that you start over. Once you've scraped some data from a drive, it is never a good idea to throw it away and start over. But it would be a good idea to go ahead and grab the part that you missed: ddrescue -B -n -s 63 /dev/hda rescued_mbr.ima rescued_mbr.log (That's assuming that /dev/hda1 starts at sector 63. You can check that with "fdisk -lu /dev/hda".) You're gonna have a little chore, eventually, putting the two pieces back together... you'll have to do something like this (assuming that /dev/hdb is a scratch drive, and /dev/hdc is the eventual new drive): # Copy the MBR / primary partition table: ddrescue -B rescued_mbr.ima /dev/hdc # Copy the first (only?) data partition: ddrescue -B /dev/hdb /dev/hdc1 Secondly, I think you mistake how SpinRite works. Your step #4 needs to run SpinRite on the original (failing) drive, not on the copy. (Note: my ddr2sr.pl "ddrescue-to-SpinRite" script will help you target just the bad areas of the drive with SpinRite.) When ddrescue finishes, before you run SpinRite, the new copy will have only two kinds of sectors: those which contain perfect data, and those which have nothing at all (probably zeros, if /dev/hdb was initially all zeros). Then, when SpinRite has finished working on the bad sectors, you'll have two kinds of formerly-bad sectors: Those which were fully recovered (probably about 10% of them), and those which were only partially recovered (the other 90%). You can then use ddrescue to add the (fully & partially) recovered sectors to /dev/hdb. But be sure to save a copy of your rescued.log file first, because ddrescue can't tell the difference between the fully recovered sectors and the partially recovered sectors -- they will all read "successfully" when ddrescue sees them. So, after you use ddrescue to add the SpinRite-recovered sectors to /dev/hdb, the rescued.log file will no longer be an accurate record of which parts if the drive are damaged. (Dd-rescue's logfile has no mechanism for representing damaged/partially-recovered sectors.) But the combination of the new and old ddrescue log files, plus the SpinRite logfile, encapsulates that information. My ddr2nfi.pl tool uses all three logfiles to generate NFI commands for the truly damaged sectors, for trying to deduce which files are impacted by the damage. (Note: run the resulting .bat file of NFI commands on a scratch copy of the recovered drive, not the main/best copy, since Windows always "messes with" a drive when it mounts it.) For hours of entertainment, download my Perl scripts that I use when doing dd-rescue recoveries. One http://www.burtonsys.com/download/ddr2sr.zip It contains: clustersize.pl -- "Shows cluster size(s) for FAT and NTFS partitions" ddrsummarize.pl -- "Summarize a ddrescue log file" ddrsplit.pl -- "DDRescue logfile SPLITter" ddrcombine.pl -- "DDRescue logfile COMBINEr" ddrlogand.pl -- "DDR LOGical .AND." ddrlogor.pl -- "DDR LOGical .OR." ddrlognot.pl -- "DDR LOGical .NOT." ddr2sr.pl -- "ddrescue-to-SpinRite" ddr2nfi.pl -- "DDRescue to NFI" nficruncher.pl -- "Process the output of many NFI commands" fat32inf.pl -- "FAT32 info (this one is still under construction) foreach.pl -- "Repeat a command for each filename or argument" ddrcopyincrement.pl -- "Copy additional recovered sectors" ddrwipe.pl -- "Obliterate all the GOOD sectors on a failing disk drive" samplescripts.zip -- some shell scripts ddrescue_perl_helper_programs.txt -- documentation (see also comments in the scripts) There are examples in the samplescripts.zip of using a "raw" device for a later "pass" to read sector-at-a-time, so that the unrecovered parts will be down to a granularity of one sector, instead of a full Linux buffered disk block. Unfortunately, raw devices vary in implementation between Linux versions, so you might have to fiddle with the scripts to make that part work. Unfortunately, some of the other scripts assume that the destination is a copy of the full drive, including MBR, and expect the logfile to describe a whole drive. After you put the two recovered pieces back together, your rescued.log file will not properly describe the "holes" in your entire /dev/hdc drive, since all the LBA sector numbers will be off by (probably) 63. But you could fix it pretty easily with a little (Perl?) program that runs through the logfile and fixes up the sector offsets. For your step #5 (which seems optimistic, at this point, due to the apparently rather severe damage to that drive), if the XP registry files are damaged, might need to recover a good copy of the registry from the system restore points. Contact me for the .bat script I've written to do that, if you get that far. For your step #6 (which seems more realistic for this drive), you can use xxcopy (a very nice shareware tool), and a command like this: REM xxcopy_only_missing_files.bat REM REM Copies from source (%%1) to destination (%%2) directory tree REM only those files which do not already exist in the destination REM directory tree, except does not copy empty directories. REM REM Example: REM xxcopy_only_missing_files.bat H:\ I:\ REM xxcopy %1 %2 /H /K /BB /S /Q /ZE Get xxcopy here: http://www.xxcopy.com/ For your step #7, Microsoft's "nfi" utility is your friend (assuming that it is an NTFS file system). Two of the Perl scripts in my collection are helpers for this chore: ddr2nfi.pl -- "DDRescue to NFI" nficruncher.pl -- "Process the output of many NFI commands" Download NFI from Microsoft's web site: http://www.google.com/search?q=%22ntfs+file+sector+information%22+site%3Amicrosoft.com A few months ago I posted some other notes on this process here: http://www.linuxquestions.org/questions/showthread.php?s=2156247cf74a1f0b7e8a0b3b58400dd0&p=2439434#post2439434 (The question asked was about the Linux ReiserFS file system, but, silly me, I didn't read it carefully, and posted an answer that included instructions for NTFS data recovery.) As for your step #9, just forget it. That drive's toast. Get what data you can from it, and when you are done just junk it. (Or sell the PCB from it on eBay... someone might need it for a drive with a fried PCB.) Good luck! -Dave Burton geek at burtonsys.com but please no spam Geeks Alive Computer Rescue: http://www.geeksalive.com/ PO Box 4157, Cary, NC 27519-4157 USA Tel: 1-919-481-2183 Cell: 1-919-244-3316 [EMAIL PROTECTED] (Matt Boge) wrote: > Hello, > > I ran across your tool while searching for solutions to rescue > data from my failing hard drive. I am a newbie to Linux, but I > am technical and can understand and follow directions. > > Anyway, my 200GB NTFS failed to boot the other day, with > Windows XP telling me it couldn't read a required file. > Subsequent tests, specifically the Maxtor utility, told me that > the drive was failing and I needed to replace it. I attempted > to repair with the Windows installation disk, but it failed, > citing read-errors on the disk. This is when the panic began > to set in... > > I looked around for some tools that I remembered would do a > bit->bit copy and if it ran into errors, would ignore them and > move on. I wanted as much data as I could get to be on a good > drive as soon possible before the drive really kicked the > bucket and I was hoping that I could clone the disk, have > Windows repair the bad file and not have to reinstall all my > apps. I looked at Ghost and some others, but settled on > Acronis True Image, as it seemed to do what I wanted. > Unfortunately, it appears that True Image works best on a > healthy drive and I was never able to get the image copied (the > status bar never moved... even after 24 hours). I thought > perhaps since the drive I was copying from was IDE and the new > one was SATA it could have been the problem. So, I bought a > 250 GB IDE drive and it still didn't work. Now, I was truly > worried about just getting the data off of it. > > After some more searching I found your utility from the article > I found on this page: > http://www.cgsecurity.org/wiki/Damaged_Hard_Disk > > I'm pretty inexperienced with Linux, but I have dabbled a > little (upgrading my TiVos, for example) and your tool looked > like exactly what I needed. I downloaded Knoppix, managed to > install ddrescue from a floppy (it wasn't included in Knoppix) > and -- after realizing I needed to be logged in as 'root' -- > ran the following command from a Konsole terminal window: > > ddrescue -B -n /dev/hda1 /dev/hdb rescued.log > > (This was the recommended command from the above guide to "grab > most of the error-free areas in a hurry") > > That was about 24 hours ago and while I suppose "in a hurry" is > a relative term, as I type this, here is what the current > console status looks like: > > Current status > rescued: 5742 MiB, errsize: 29612 KiB, current rate: 2304 KiB/s > ipos: 5771 MiB, errors: 595, average rate: 140 KiB/s > opos: 5771 MiB > Copying data.... > > Does that look about right? Seems to me at this rate (approx > 5GB/day) it's going to take about a month to complete... am I > reading this wrong? > > So I guess my first question would be did I use the correct > command to copy over the good data quickly? > If not, what should I be doing? > > Secondly, here is my attack plan... I would appreciate it if > someone would tell me if it looks OK: > > 1. Copy the good data to a brand new HD (Copy1) using > ddrescue. <-- This is where I am now. > > 2. Attempt to copy from the bad sectors using ddrescue. > > 3. Remove the failing HD and put aside. > > 3. Make another copy (Copy 2) from the first copy to another > HD (Copy 3) -- I'm assuming it would be OK if this new HD is > SATA, right? > > 4. Use SpinRite (another recommended utility) to attempt to > repair the bad sectors on Copy 3. > > 5. Attempt to repair WindowsXP with the repair utility on the > install CD (again, on Copy 3. In my perfect world, Windows > would repair successfully and I could find out which of my data > files couldn't be repaired and go from there.) > > 6. If that won't work, I would install XP on a brand new drive > and try to copy the data files from Copy3 to the new install. > > 7. Identify what files didn't make it -- not sure how I'm > going to do that yet, but I'll cross that bridge when I come to > it. > > 8. Attempt to rescue those files specifically -- I'm not sure > if I should try off of the original disk or from one of the > copies. > > 9. Once I'm satisfied I tried everything I could to get all > the files I need... I will probably run SpinRite on the > original failed drive and see what happens. > > Does this seem like a prudent course? What am I missing? > > Thanks for all the help, guys... and just a quick reminder > while you're reading this: DO A BACKUP RIGHT NOW! > > - Matt B _______________________________________________ Bug-ddrescue mailing list Bug-ddrescue@gnu.org http://lists.gnu.org/mailman/listinfo/bug-ddrescue
