Le 01/09/2022 à 00:24, David Wright a écrit :
-R --reverse will start an attempt from the end of the disk, and if
you're extremely lucky, it might copy most of the remaining 960-odd GB
of data. OTOH it might only confirm that the disk is closer to meeting
its maker than it was when you started the rescue.
Thank you all for yours anwsers.
Following the suggestion of Cindy I rebooted the computer to see if
session's reboot freshness affects transfer. It did not in my case.
Transfert rate is very slow but ddrescue make some progress. After 5
days and one interruption (for rebooting), here is the current status:
---
# ddrescue -n /dev/sdb
/media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/image_HDD1.img
/media/sara/2274a2da-1f02-4afd-a5c5-e8dcb1c02195/recup_HDD_sara/recup.log
GNU ddrescue 1.23
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 33992 MB, tried: 0 B, bad-sector: 0 B, bad areas: 0
Current status
ipos: 72645 MB, non-trimmed: 26050 kB, current rate: 1638
B/s
opos: 72645 MB, non-scraped: 0 B, average rate: 55829
B/s
non-tried: 951012 MB, bad-sector: 0 B, error rate: 0
B/s
rescued: 49165 MB, bad areas: 0, run time: 3d 3h
29m
pct rescued: 4.91%, read errors: 490, remaining time: 5382d
14h
time since last successful read:
0s
Copying non-tried blocks... Pass 1 (forwards)
---
I am considering using -R option (as suggested by David Wright) to see
if ddrescue can have better transfert rate starting from the other side
of the HDD. My concern is whether or not ddrescue can resume a job
started, stopped, and relaunched with -R option added. ddrescue's manual
says only:
--reverse
Reverse the direction of all passes (copying, trimming, scraping,
and retrying). Every pass that is normally run forwards will now be run
backwards, and vice versa. '--reverse' does not modify the size of the
blocks copied during each phase, just the order in which they are tried.
If I stop ddrescue and add -R option, would the mapfile be able to
handle this (ddrescue started from the beginning and the end the the
drive)?
I also add some information related to other answers:
- The destination HDD is an external USB3 one. It is a physical RAID 1
with two 8To HDD 7200rpm. The commercial name is Lacie 2big raid. The
fact is image is growing and the speed seems to vary (even if never
fast) lets me think it is perhaps the HDD condition which is the cause
of the slow transfer rate.
- I commented out the failing HDD in /etc/fstab and disable
smartmontools tests for this drive. I did not try to mount the HDD.
Cheers.
ppr
