NOOB, I don't know where to begin describing my problem / attempts at recovery.

[Randall Meyer]

Hello,

I guess I should start saying I am as scientist, biologist, and Linux dabbler 
(since about 2015). Some TI-BASIC (TI-82), mid 90s, in high school, and some 
6502 assembly, early 2000s after college, but couldn't afford to pursue my 
interest in MASM AND TASM and "real computing", at the time.

Fast forward to now, I run a Windows 10 "air-gap" computer (until 6 months ago, 
air-gap; I can't STAND forced updates!), on a Dell 6520 laptop, a laptop I 
purchased in 2020 because I know the hardware, inside and out, having taken 
apart my Dell Latitude 6420 (every single screw !) back around 2018 (purchased 
the 6420 in 2015, immediately blocked up by Windows updates, and so I switched 
to GNU/Linux for the first time in my life, after only 2 or 3 months of Windows 
10).

Anyhoo, preliminaries out of the way, I have what I believe to be a failing 
drive on my 6520, but I recently have taken the thing on-line, with one of the 
earliest and simplest builds of Windows 10, and I FINALLY managed to turn off 
all the forced updates and forced uploads. Luckily, I have a 128 Gb flashdrive 
with puppylinux on it (fossapup build) and I can access the internet for advice 
while I try to assess the slow HDD (2.5" laptop type: not big desktop 3.5" 
internal). But my point is, perhaps windows is corrupted, by a virus or just 
regular internet-clog, and that's why it is slow? But perhaps it is the drive. 
The SMART test was a bit inconclusive.

I have been "at it", 3 days (8 or 10 hours each day), trying first, dd, but 
then realizing I lack some skills that are essential, and finding gddrescue, i 
figured a push-button solution would be better.

But this has not proved to be the case.

If I can't figure out ddrescue today, I might revert to dd, and take notes on 
the sectors completed, each day. And begin each new day with a new "seek" 
and/or "skip" command.

So, my problem with ddrescue, I think, has to do with the logfile and the lack 
of regular-persistence with puppyLinux. After my second day using ddrescue 
(copying the same 12GB overtop of the first day, ) I made CERTAIN that I saved 
a logfile and even saved extra copies of that logfile onto other flashdrives.

I was worried that booting the computer the next day, something might happen 
with the persistnece of the logfile and it would vanish. But I started up today 
and the logfile was there (on the puppylinux flashdrive) and it appeared to 
have the correct information.

So i entered my command : " ddrescue /dev/sda /dev/sdc logfile" (Same I entered 
yesterday... except I plugged things in in different sequence so sdc yesterday 
was actually sdd)

(sda is internally installed 2.5" HDD, installed in the laptop I am presently 
using, probably via 
PCIe/northibridge/southbridge/some-crap-I-dont-know-or-understand, sdb is the 
128 GB puppylinux flashdrive running the OS, with SOME persistence, at least, 
functional, and sdc is a USB 2.0 connected (probable choke-point !!! yup !!! 
USB 3.0 or eSATA or SATA would be better !), 3 TB hitachi HDD, 3.5" 
manufactured in Nov. 2012 (refurbished? maybe? But I think it was bought "new" 
from NewEgg? sda has 2 partitions. I only created one partition on sdc, and 
only put 320 GB on there even though the other drive is 300GB (not much 
"headroom"?), but either ddrescue or dd has put two partitions into the one I 
put there. So that seems to be automatic? Windows 10 has a small 500MB parition 
and then the rest of the drive is its own partition)

It gave me an error.

"output is not a regular file"

"use -f for force if you are certain that you want to force it."

or words to that effect.

I was NOT certain I wanted to force it, but I figured at worst I lose one more 
day. After brief internet searches for similar problems and similar situations, 
I found few or none, and risked it.

BAAAAHHH! Starting over AGAIN today !!!!

320 gigs total and I've written the same 12 or 15 or 25 GB over three times now 
! once with dd, twice with ddrescue, and today is number 4 ! 4th time around.

Also, I have been loathe to increase the block size as I do not want to lose 
granularity/specificity/accuracy/precision in a quest for speed. And I do not 
want to force the drive to work harder or faster than it has to, or should.

But with lengths of time like those I am witnessing, I think that will likely 
damage the drive more and result in only a partially copied drive, i.e. useless 
data, completely.

I think, If I scrap my latest ddrescue attempt, right now, I can start it with 
dd, and define a larger block size, and then write down my progress at the end 
of each day.

Unless you know why my ddrescue isn't working?

Perhaps the command I used should name the logfile something different? Why is 
there no entry in the command for "load from THIS logfile and save as THAT 
logfile2"?
Regards,

Randall Meyer

P.S. I am reading and re-reading your documentation, and I'm not sure it is 
helping. But maybe I identified one other thing I am doing wrong?

I might run afoul of this particular piece of advice: I've hidden nothing ?
"

If you interrupt the rescue and then reboot, any partially copiedpartitions 
should be hidden before allowing them to be touched by anyoperating system that 
tries to mount and "fix" the partitions it sees.  

"