Re: DDRescue screwed up on NTFS drive backup, partition won't read now

[Hamish McIntyre-Bhatty]

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,
> Antonio.
Hello,

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).

Best,
Hamish McIntyre-Bhatty