On 25/05/2022 18:20, Antonio Diaz Diaz wrote:
Hi Travis,

Travis Sherwood wrote:
Thank you for replying so promptly. The exact tool I performed the
procedure with is DDRescue-GUI, found here: https://www.hamishmb.com/

I have never used DDRescue-GUI (nor any other GUI frontend). I prefer to interact directly with ddrescue from the command line.

So far, the consensus has been that the Source and Destination drives
were switched around. As for how this occurred, I have no idea because
the procedural matters left zero chance for human error. The WD Elements
drive never gets unplugged and is the only external drive used on this
system. This rules out any possibility of it changing its designation
from SDB to anything else.

I'm sure you were diligent. The only explanation I can find is that between your selection of drives in DDRescue-GUI and the actual call to ddrescue, some automatic feature of the kernel or of Ubuntu managed to switch the device names. I still use linux 3.2 and have removed all automation from my system. I mount devices by hand, etc.

But since the One in a Million chance did happen, a final Confirmation
Message to list Source (Designation and Description), Destination
(Designation and Description) and Procedure seems like the simplest
solution to prevent this from occurring again. Do you think this could be
implemented in the next version?

Ddrescue already implements a final confirmation with the option --ask:

$ ddrescue -f --ask /dev/sda /dev/sdb
GNU ddrescue 1.27-pre1
About to copy 500107 MBytes
from '/dev/sda' [SAMSUNG HD502IJ::S13TJ9BS200514] (488_386_584Ki)
   to '/dev/sdb' [SAMSUNG SV1022D::0255J1EN821966] (10_203_684_352)
Proceed (y/N)?

Maybe Hamish could make DDRescue-GUI pass the option --ask to ddrescue so that the user has a chance to abort the copy if something changed in the last minute.

I am sorry for your trouble and I hope you can recover your data.

Best regards,


I came to the same conclusion - the drives were mixed up, and the logs told me it was user error. Adding the --ask option, or an equivalent, is a good idea though, and that will be present in the next version.

Out of interest, is there a drive mixing-up issue with kernels newer than 3.2 then? I tend to use /dev/disk/by-uuid doing bootup, but hadn't heard of issues like this occurring once the system has booted (sometimes firmware updates mix my drive numbering around though).

Hamish McIntyre-Bhatty

Reply via email to