If the logfile is larger than '--logfile-size', read sequentially the largest non-split blocks until the number of entries in the logfile drops below '--logfile-size'. Repeat until all remaining non-split blocks have less than 7 sectors. Then read the remaining non-split blocks sequentially.
Every bad sector is tried only once in each pass. Ddrescue can't know if a bad sector is unrecoverable or if it will be eventually read after some retries. The total error size 'errsize' is sum of the sizes of all the non-trimmed, non-split and bad-sector blocks. It increases during the copying phase and may decrease during trimming, splitting and retrying.
Note that as ddrescue splits the failed blocks, making them smaller, the total error size may decrease while the number of errors increases. The logfile is periodically saved to disc, as well as when ddrescue finishes or is interrupted. So in case of a crash you can resume the rescue with little recopying. The interval between saves varies from 30 seconds to 5 minutes depending on logfile size larger logfiles are saved at longer intervals.
Also, the same logfile can be used for multiple commands that copy different areas of the input file, and for multiple recovery attempts over different subsets. See this example:. Rescue the most important part of the disc first. Then rescue some key disc areas. Now rescue the rest does not recopy what is already done. Even though the question was asked 10 months ago, the answer might be relevant because the recovery cycle might still be running depending on a few factors!
No pun intended. The reason is that, time estimate is almost impossible, however sometimes you could get a rough idea as follows. One of the most obvious reasons is that you can't predict how long it will take the drive to read a bad sector and if you want ddrescue to read and retry every single one, then it could take a very long time. For example, I'm currently running a recovery on a small GB drive that's been going on for over 2 weeks and I possibly have a few days left.
But mine is a more complicated situation because the drive is encrypted and to read anything successfully, I have make sure to get all sectors that have partition tables, boot sectors and other important parts of the disk.
I'm using techniques in addition to ddrescue to improve my chances for all the bad sectors. IOW, your unique situation is important in determining time to completion. By estimate of "loops", if you mean number of retries then that's something you determine by the parameters you use.
If you mean "total number of passes", that's easily determined by reading about the algorithm here.. I'll specifically speak to the numbers in the screen captures you provided.
Other situations may have other factors that apply, so take this information as a general guideline. I'm recovering the data from the bad hard drive to a good hard drive which is connected to the system using a USB external hard drive enclosure. Given how close to GB the process seems to be, I don't want to cancel it but it's been "this close" for the past 12 hours, at least. Can I safely cancel the process or should I just let it run?
Matt Beckman Matt Beckman 1 1 gold badge 4 4 silver badges 8 8 bronze badges. Its by design, most likely. Crash a smaller hard drive next time ;- — Joey. My 4TB has taken 3 weeks to get to the Trimming phase I'm pretty sure it's all backed up, but doesn't hurt to rescue ; It's done! Scraping was really fast even though it was 1. I'm running again with -M just in case this morning's reboots and dist-upgrade made some sort of mess — Stephen.
Add a comment. Active Oldest Votes. Probably the -i input position flag can help speed up things too. Improve this answer. Kamil Maciorowski The -n option in GNU ddrescue is --no-scrape , not "no-split" — endolith. I had a 3 hour clone that was reduced to 30 minutes by using -c I would have thought that having it be larger would have been faster.
A simple command ddrescuelog -t YourLog. Karl Richter 1, 3 3 gold badges 32 32 silver badges 53 53 bronze badges. MvG MvG 1, 2 2 gold badges 12 12 silver badges 25 25 bronze badges. How exactly to do that? By the way, there is a wonderful graphical application to analyze the log. Josep Josep 51 1 1 silver badge 2 2 bronze badges. That graphical program is awesome — endolith. One more way to monitor ddrescue's progress on Linux, at least is through the use of strace. Well, I looked at the log fie, and I dont find a very regular pattern.
Seems that the second part has more errors than the first one. The harddrive is still getting recognized, I was able to even get off some files, but there are sections that cannot be acessed anymore. So I thought with an image I have more chances to recover some files than from a damaged drive that gives me constantly read errors.
But yes, the imaging was only sucessful unto this point…. I dont know, if it is useful I can send you the logfile. But it seems to me it is not that much of a regular pattern. If you have some more hints, let me know. When trying to recover data it is important not to stress the drive with too many retries.
I have never used ddrescue but are the sectors on the disk you copied to in the correct location? Also, was the disk clean before you started the copy?
If the disk was not clean, you will have major problems with 'data contamination'. You may be luck and get some files back logically, but otherwise you may need to use data carving and hope your data is not too fragmented.
Some parts of the disk typically read better than others. These are often the most useful sectors, but also the hardest to recover. However, they don't contain user data which can sometimes be recovered by other means. I doubt you can do much more than let the drive cool completely and try again sometimes a not-warmed up disk allows to read a bunch of sectors more , all the rest would need a pro examining and diagnosing properly the issue and if possible repair the problem , though if it is a head or a translator this may be possible, if it is the actual platter surface the data is gone for good.
I actually tried now to do a separate image of just the first 5 GB. It works fine in the first 2 phases of ddrescue, but as soon as it comes to the splitting phase, it is stuck again Looks like the drive is not totally dead at least.
Has within 5 GB some MB failed sections, and cannot split, not a single one. I tried already to let the drive cool down and start again, but no change. For your info, it was running 20 days recuperating with success, but then in the splitting phase days stuck with no progress at all.
0コメント