1

I am trying to recover data from a failing usb hard disk using ddrescue. I ran ddrescue for about 4 days at the end of which it completed pass 1. Sometime after it began with pass 2, I interrupted the process to give the laptop and hard disks a break as they were getting heated up. When I restarted ddrescue, I found that it had resumed at the spot it had left previously, but with pass 1 counting upwards again and not with pass 2 (counting down). Moreover the second pass was painfully slow covering only 5 Gb for the next 2 days. The Current status shows 0 errors and errsize as 0B and rescued as 769755 MB which is roughly the amount of data I remember being on the drive. My question is can I assume that ddrescue has already recovered the data there is to be recovered and that it is safe to extract the contents of the image file to another usb drive? or is it necessary/mandatory to let ddrescue run the remaining two passes as well?

P.S Chkdsk failed with usb hard disk with "An unspecified error occured" message. I am hoping to extract the image file to a new hard disk and run chkdsk again to see if that can fix it. Tried mounting the image file in linux, but it came back with NTFS signature missing.

1

Did you provide a log/map file to ddrescue? For example:

# ddrescue /dev/sdc file.img map.txt

If you provided a map file, then ddrescue should resume where it left off. This means that it will not attempt to re-rescue all the data it originally rescued, and it will only retry the bits it was having trouble with. However, as far as I know, passes are irrelevant across restarts. The map file is used so ddrescue can know what data it has already covered, and where it had trouble, and what phase of the algorithm it is currently running. However, passes only count how many times ddrescue has been through the disk in one phase, but do not seem to be recorded in the mapfile. If you interrupt it in the middle of "pass 2", then run it again, it'll effectively be running a brand-new "pass 3" that it'll call "pass 1", but it won't redo anything it already covered in pass 1 or the partial pass 2. In this case, it's expected that it would have lower throughput: everything beyond the original pass 1 is trying to read the trouble spots. ddrescue works by first trying to recover all the easily readable bits of the drive as fast as possible, then going back and trying again on the parts it couldn't read. After restarting it, you should find that the "rescued" value is the same as where it left off during the previous run.

If you did not provide a map file, then there is no way to resume where you left off - stopping ddrescue and starting it again is basically equivalent to starting from scratch, because it can't know what data it has already taken care of or not. You should always use a map file when you are rescuing data from a failing disk.

All in all, ddrescue will exit when it has finished recovering 100% of the drive, or when it gives up retrying to recover data. You should let ddrescue run to completion, unless you're willing to give up on any remaining data it hasn't been able to read yet. You should always allow at least one full pass to complete, otherwise you'll be missing out on perfectly good data (if you allowed the very first pass to complete, then that is covered). The amount of data recovered is relative to the complete size of the drive, not the amount of files that were actually on it, so if it has recovered 769755MB out of a 1000000MB drive, that means ddrescue has recovered ~77% of the total sectors/blocks on the drive, but it can't know whether that 77% corresponds to in-use blocks, or to free blocks. If the drive was 77% full, in the best case, you've recovered 100% of your data and filesystem structures (if you get improbably lucky). In the worst case, you've recovered all of the useless 23% of the drive which is empty space, and a further 77-23=54% of the drive in data. If the drive was 77% full, that's .54/.77 = about 70% of your data. On average, if the fraction of the data recovered is random, you'll have about 77% of your data. If you get unlucky, it may miss important filesystem structures making the rest of the data very hard to recover.

  • Hi marcan, thanks for the extensive response..I have provided a mapfile, which is why it is able to pick up at the spot at which it left, but only in the wrong direction. I found out an option --cpass=2 which allows me to resume the backward pass without waiting for the forward pass to complete once more..but this resumes not from the spot that ddrescue left last time but from the end of the disk i.e., at the point where the forward pass would have completed - so when I interrupted sometime into pass2 with ipos/opos at 962695Mb it resumed at 999864. – Venkatkk May 12 '16 at 9:14
  • To clarify ddrescue has completed only one pass of phase 1 which is copying. Trimming and scraping phases still to go after that. Can you please clarify the 77% of data remark - I mean if I say that the amount of data on my hard disk was 769 GB and the rest was free space, what you're saying that the 769755 MB figure that ddrescue is mentioning is not the 769 GB of data on the disk I saw but only 77% of that 769 GB. Maybe it would sense if the 769755 figure is viewed as blocks - the MB attached to it is what is confusing. – Venkatkk May 12 '16 at 9:23
  • Good point, I mixed up the nesting of phases/passes in my head. So, you've completed two passes of the first phase, which means ddrescue hasn't had a chance to apply some of its later algorithms. What that means is that there is probably more data left to recover. Supposedly, the mapfile does contain a line indicating the current position, but it doesn't contain the pass, which explains what you're seeing. – marcan May 12 '16 at 10:48
  • As for 77%, what we need to know is the total size of the disk. If it is a 1TB hard disk, then 769GB is ~77% of that. That means ddrescue has recovered 77% of the contents of the disk, whether they be data or free space (it can't know). I'll update the answer to clarify. – marcan May 12 '16 at 10:52
  • Thanks again for the response..Just checked this morning..noticed that ddrescue has completed 23GB out of 1000GB since yesterday with remaining time at 2years, 361 days 6hours :(..not sure if this includes all phases or just this pass alone..the rescued figure has gone up a little bit from 769755 to 770238. I am having doubts as to the sanity of the data that ddrescue is building in the image file because the file system on the hard disk is corrupt..mount returns ntfs signature missing message..chkdsk does not complete..so will it run fully even if ddrescue completes fully and gives one image – Venkatkk May 13 '16 at 8:16
0

ddrescue works on blocks not on files. On a 100Gb drive where you had 60Gb of data, you can have recovered blocks to the amount of 60Gb, but that only means for sure that 20Gb of your data has been recovered. The chances that the 60Gb of blocks cover exactly the data are slim.

You should IMO let ddrescue run (and in the mean time reconsider if restoring from backup isn't more cost effective even if you loose a few hours of data changes that occurred between the backup and the crash)

  • Anthon thanks for your response..I am afraid I dont have a full backup of the data which is why am having to go through this hell..I have taken a partial backup of most of the important stuff that was on the drive..but theres still some stuff left that I was not able to get out in time..on the subject of backup..can you please suggest which is the best I software I can use for the purpose. – Venkatkk May 12 '16 at 9:28
  • I have used ddrescue as well, it just takes forever if the drive errors out on sectors. As for backup software, don't know what your setup is. Tapes have become horribly expensive for todays general disc-capacity, so I backup to (pluggable) disc with rsync and do an hourly sync to a remote system that then does a snapshot on the changes. – Anthon May 12 '16 at 9:53
  • Hi Anton, Thanks again..I will surely check out rsync..Just to share I came across a neat little tool called filesync and tested it out briefly..seemed to work fine..but haven't tried it on large amounts of data though.. – Venkatkk May 13 '16 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.