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

[Michal Ambroz]

Hello Randal, 
if I understand right ... you are trying to copy 320GB from old failing disk
to new disk with command

ddrescue /dev/sda /dev/sdc logfile


1) info
it might help to post some info about the disks and their status

fdisk -l /dev/sda  #(to see the disk size and partition table of the 
original disk)
fdisk -l /dev/sdc  #(to see the disk size and partition table of the target
disk) 

smartctl -a /dev/sda # check the health of the original disk


smartctl -a /dev/sdc # check the health of the target disk





>  I have what I believe to be a failing drive on my 6520,

> The SMART test was a bit inconclusive.



One of the most interesting infos would be RAW_VALUE of the Reallocated_
Sector_Ct as it might give idea how much is the disk failing.






Please attach the logfile to see what it has done so far.




Assuming you have the target disk big enough and not failing by itself.





2) first copy what is possible, then focus on broken parts

One of the biggest benefits of gnu ddrescue is that you can do subsequent 
runs and it wont lose what you copied before.

Be more generous skipping the badblock with first runs, make it more
specific with subsequent runs with option --skip-size.
Like starting with :

ddrescue --force --skip-size=10G,10G /dev/sda /dev/sdc logfile




Then skipping less with the subsequent runs:

ddrescue --force --skip-size=1G,1G /dev/sda /dev/sdc logfile


ddrescue --force --skip-size=10M,100M /dev/sda /dev/sdc logfile




ddrescue --force --skip-size=10M,100M /dev/sda /dev/sdc logfile






> 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.
You might very well combine ddrescue and dd, but keep in mind that ddrescue
does no truncating of the file by default (=good) and automatically
synchronizes seeks with skips (the block 1234 copied from sda will be copied
to block 1234 on sdc). 


With dd (as a more general transformation tool) you need to know what you 
are doing and enforce these manually with each subsequent run.
For example this would be dd trying to start from the 100GB in the middle of
disk:

dd if=/dev/sda of=/dev/sdc bs=1M iseek=100000 oseek=100000 conv=notrunc


You might need to add also iflag=direct when trying to recover certain 512B
blocks, smaller than the default sector size of 4kB/8kB. 





> So, my problem with ddrescue, I think, has to do with the logfile and the
lack of regular-persistence with puppyLinux. 

Persistence of the logfile is a key to success !!! Without that you wont be
able to use ddrescue successfully.
Depending on your hardware you might need to reboot (or at least disconnect
the disks) each time it hits the area with the bad sectors.
You really want to have the logfile stored with the status, what has been 
done so




Rather than laptop I would recommend to use some old desktop, where you can
physically disconnect drive, once it becomes unresponsive, 
and with bit of luck your hardware might be capable of hotswaping the disk
like that.




On laptop, you might still try suspend/hybernation to achieve the same power
-cycle on the faulty harddrive.

It depens how much is your hardware fault tollerant and how well it is
capable of surviving the situation.




> sdc is a USB 2.0 connected (probable choke-point !!! yup !!! USB 3.0 or
eSATA or SATA would be better !)



Even if everything would go well, the USB 2.0 would be killing the transfer
time. USB 2.0 would do something like 15 MB/s,
while your physical rotating drive could do like 100MB/s, SSD drive even 
more.




Best regards

Michal Ambroz





---------- Původní e-mail ----------
Od: Randall Meyer via Bug reports for ddrescue, data recovery tool. <bug-
ddrescue@gnu.org>
Komu: bug-ddrescue@gnu.org <bug-ddrescue@gnu.org>
Datum: 11. 5. 2023 23:50:12
Předmět: NOOB, I don't know where to begin describing my problem / attempts
at recovery.
"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.  

"
"