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- ddres...@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. " "