Dear Antonio,

I have a few questions regarding ddrescue, after several unsuccessful
trials (and several weeks of ongoing process), and I imagine I might be
misusing the command at some point.
As I wrote in my first email to you, my goal is to recover ~140 Gb of data
stored on a 2 Tb external HDD (single partition, NTFS type)

Amongst the main trials that I did:
- disk to disk (infile /dev/sda and outfile /dev/sdb, for instance)
- partition to partition (infile /dev/sda1 and outfile /dev/sdb1, for
instance)
- partition to image (infile /dev/sda1 and outfile
/media/sdb-disk/image_file)

I also tried to minimise / optimise the rescued area, by using ddrutility,
but so far without success (because the image that I got was not usable).

My questions are:
- whatever the outfile format (disk/partition/image), is it necessary that
the HDD used for the recovered object has the same partition type (MBR or
GPT, for instance) that the rescued disk itself?
- and is it necessary to have a partition with the same format (NTFS), or
no partition (free unalocated space) on the destination HDD?
- regarding the ddrescue process, I noticed that the copy phase is going
1-forward 2-backwards 4-backwards (again) and 5-forward, while the manual
says that every pass goes the opposite direction than the previous one. Is
it expected that the pass 3-forward is skipped? (I didn't used any options
related to the phases).
- I also noticed that the copy phases have orders of magnitude between
their duration: for instance, the ongoing process lasted for ~2hours (copy
pass 1 forward), then ~1h30 (copy pass 2 backwards), then 6 minutes (copy
pass 4 backwards), and currently > 6 hours for only 130Mb of the 5th
copy-pass (forward) with a remaining time displayed as 1913 days. While the
first 2 passes are expected to skip large chunks of disk in case of slow
response of the rescued disk, the subsequent two passes (3 and 4 or 4 and
5) are described as proceeding more slowly, but with the same rule, so I
don't understand why the former last for only 6 minutes, while the second
is utterly slow.

Could you maybe give me some hints to tackle this situation?

Kind regards

Bruno

Le dim. 8 mars 2026 à 09:57, bloup38 <[email protected]> a écrit :

> Dear Antonio,
>
> Thank you very much for your answer, and suggestion to use the option '-a,
> --min-read-rate'.
> In between, I also tried to use the option -O which seemed suited, after
> noticing that the reading rate was dropping after a slow or bad area,
> without recovering unless I restart the process. Option -O apparently has
> the same effect of a manual restart, and indeed the backwards pass 2
> finished during the night. Still a long way before the rescue ends, but one
> step at a time.
>
> Best regards
> Bruno
>
>
> Le dim. 8 mars 2026 à 00:24, Antonio Diaz Diaz <[email protected]> a écrit :
>
>> Dear Bruno,
>>
>> Bruno Loup wrote:
>> > First, I would like to thank you for providing ddrescue tool to the
>> community.
>>
>> You are welcome. :-)
>>
>> > I noticed some very slow regions of the disk, that I would like to skip.
>> > I tried to use the -K (or --skip-size=) option, but it seems not to work
>> > during backward pass:
>>
>> You need to use the option '-a, --min-read-rate' in order to skip slow
>> areas. --skip-size just sets the size to skip, but does not enable
>> skipping
>> of slow areas. You may try something like '-a 50kB'.
>>
>>
>> http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#g_t_002d_002dmin_002dread_002drate
>> -a
>> <http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#g_t_002d_002dmin_002dread_002drate-a>
>> bytes
>> --min-read-rate=bytes
>>      Minimum read rate of good non-tried areas, in bytes per second. If
>> the
>> read rate falls below this value during the first two passes of the
>> copying
>> phase, ddrescue skips ahead a variable amount depending on rate and error
>> histories. The blocks skipped are tried in additional passes (before
>> trimming). --min-read-rate is ignored in all passes but the first two.
>>      If bytes is 0 (auto), the minimum read rate is recalculated every
>> second as (average_rate / 10).
>>
>> Best regards,
>> Antonio.
>>
>

Reply via email to