How to split a ddrescue disk image and how to use it again

cloningddrescuemountsplit

I have a 500GB external HDD that I need to rescue the contents of. Unfortunately I only have two 400GB partitions to save the contents to. Can I split the disk image as:

~$ cd /mnt/part1/Recovery/
/mnt/part1/Recovery/$ ddrescue -f -n -i0 -s250...00 /dev/disk disk.part1.ddraw disk.part1.log
/mnt/part1/Recovery/$ cd /mnt/part2/Recovery/
/mnt/part2/Recovery/$ ddrescue -f -n -i250...00 /dev/disk disk.part2.ddraw disk.part2.log

(values of numbers are missing a few zeros for convenience). That is, can I just use the -i and -s flags to split the disk image into two parts manually?

Secondly, is there a way I can mount the two parts of the image as one?

Best Answer

To answer the second part of your question. How to mount a FS stored in two files (a and b) Two options I can think of:

Using device-mapper and loop devices:

losetup /dev/loop1 a
losetup /dev/loop2 b
s() { blockdev --getsize "$1"; }
dmsetup create merge << EOF
0 $(s /dev/loop1) linear /dev/loop1 0
$(s /dev/loop1) $(s /dev/loop2) linear /dev/loop2 0
EOF
mount /dev/mapper/merge /mnt

The idea being to do a linear device-mapper device which is just the concatenation of the two loop devices.

Using nbd-client + nbd-server

ln -s a part.0
ln -s b part.1
nbd-server 127.1@12345 "$PWD/part" -m
nbd-client 127.1 12345 /dev/nbd0
mount /dev/nbd0 /mnt

(easier but less efficient)

Here, we're using the "multi-part" mode of nbd-server that expects the parts to be named as part.0, part.1... Unfortunately, contrary to qemu-nbd, nbd-server/client can't work with Unix domain sockets which mean we have to have the TCP overhead and qemu-nbd doesn't have such a multi-part mode.

Related Solutions

How to merge two ddrescue images

If you know exactly which region of data you want to copy, you can use dd:

dd conv=notrunc if=input of=output seek=123456 skip=123456 bs=4k count=128

That would copy 128 4k blocks from input to output starting at 123456.

It would be prudent to backup the blocks you are about to overwrite first:

dd if=output skip=123456 bs=4k count=128 of=output-backup-bs4k-pos123456

If you do NOT know which region of data to copy or are unsure about it, GNU dd happens to know sparse.

dd conv=notrunc,sparse if=input of=output bs=4k

That would copy every non-zero 4k input block to output. Use bs=512 if your blocks are smaller!

Note that there isn't a backup with this method, so you better copy the file if it's important.

How to estimate loops/time for completion of GNU ddrescue (1.18.1) using current status

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 500GB 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.. >man ddrescue< / Algorithm: How ddrescue recovers the data

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.

In the sample you've provided take a look at ddrescue's running status screen. We get the total "estimate" of the problem (rescue domain) by "errsize". This is the amount of data that is "yet to be read". In the sample it is 345GB. Next line below to the right is "average rate". In the sample it is 583kb/s

If the "average rate" was to remain close to steady, this means you have 7 more days to go. 345 GB / (583 kb * 60*60*24) = 7.18 However the problem is that you can't rely on the 583kb/s. In fact deeper you go into recovery, the drive gets slower since it's reading more and more tougher areas and is doing more retries. So the time to finish exponentially increases. All of this depends on how badly the drive is damaged.

The sample you've provided shows a "successful read" was over 10 hours ago. That's saying that it's not really getting anything from the drive for 10+ hours. This shows that your drive may have 345GB worth (or a portion) of data shot. This is very bad news for you.

In contrast, my second 500GB drive that had just started giving me "S.M.A.R.T" errors, was copied disk to disk (with log file on another drive) and the whole operation took about 8-9 hours. The last part of it slowed down. But that's still bearable. While the very bad drive, as noted above is well past 2 weeks working on 500GB and still has about 4-5 % remaining to recover.

HTH and YMMV