I need to rescue data from some 2 TB large hard-drive and am doing so in some Live-Linux in some VM, where the problematic hard-drive is connected to using USB 3 and the VM provides a virtual disk of the needed size locally to receive the data. I then executed the following call, simply to see how things are going:
ddrescue -f /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
sdc is the broken device at USB,
sdb is the virtual disk to receive the data,
sda1 is for temporary storage and formatted using Ext4.
Things started to work quickly,
ddrescue was able to read ~45 GB of data within minutes, then things slowed down massively, reading only at some Bytes per second for days. So the device was obviously broken at these parts and I tried to simply skip those using multiple invocations of different
--input-position=[...]GB one after another. Depending on where I jumped to, things started to read fast again, until they got slow again and I jumped again using another invocation. The important thing to note is that input and output position printed by
ddrescue have always been in sync! I didn't manually change anything in the provided map file as well or deleted it or whatever, it has always been one and the same file and only managed by
Afterwards I changed the approach a bit and decided to not use
--input-position anymore manually, but the following instead:
ddrescue -f --min-read-rate=1MB --skip-size=1MB /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
ddrescue recognized slow parts, it skipped reasonable broken blocks of data and continued reading. Again, input and output position was in sync and the counter of read and rescued data increased all the time. Up to the point were
ddrescue finished and said to have rescued ~650 GB of data.
The problem is that after finally looking at the virtual disk files themself, it seems that only ~160 GB of data is actually stored. Additionally, the last write timestamp was some days too old. So for some reason
ddrescue thought it was reading lots of data, but didn't seem to write it properly at the places in the virtual disk where it read them from the broken disk. In the end, from my understanding the virtual disk should have had at least the size
ddrescue said about the amount of data it rescued.
I have the feeling that
ddrescue properly read all the data it said, but simply overwrote already rescued data in subsequent invocations. So while I guess it recognized
--input-position to read from, it seems to have written always starting at position 0 again at the target.
Obviously I didn't specify the start position to write data to, but according the docs that shouldn't be necessary and
ddrescue always printed input and output position to be the same anyway.
-o bytes --output-position=bytes Starting position of the image of the rescue domain in outfile, in bytes. Defaults to '--input-position'. The bytes below bytes aren't touched if they exist and truncation is not requested. Else they are set to 0.
Of course I didn't request truncation, according the docs it is not enabled by default and wouldn't even have worked for the target drive I had specified:
-t --truncate Truncate outfile to zero size before writing to it. Only works for regular files, not for drives or partitions.
So, any idea on what might have gone wrong? Were my multiple invocations with different values for
--input-position wrong already? Does it have to do with reading and writing to drives instead of partitions or files?
Maybe a problem writing to some virtual disk? Though I don't see why that should make any difference and I need to write to some virtual disk and can't provide raw device storage of the needed size.