Hi there, I'm attempting to recover data from a damaged 1TB external USB HDD to a shiny new external 1TB HDD. At the moment I only have a laptop available to do the recovery, so mounting the drives internally is not an option.
I've booted from CD (SystemRescueCD), and am using ddrescue 1.15. The command I've run to attempt the copy is: ddrescue --force -v -r 3 /dev/sdb /dev/sdc logfile The recovery has been running for a couple of weeks now (uhuh, weeks), and has been on 'Trimming failed blocks…' for the last week. Current stats are: rescued: 442932 MB, errsize: 557GB, current rate: 2048 B/s ipos: 707847 MB, errors: 5813, average rate: 255 kB/s opos: 707847 MB, time from last successful read: 0s The source disk is formatted NTFS. If I tail the logfile, I can see ongoing activity, and the current rate varies, so it seems to still be chugging away happily but slowly. My question is: if I interrupt the process at this point, can I mount & CHKDSK the destination drive and expect to see usable data? Or will the partition structure not yet be complete? Second question: I (mis)interpreted the command line reference to mean that 'logfile' should be literally 'logfile', which is what I've specified (d'oh!) rather than /path/to/logfile on a different disk (say, a USB stick). The logfile is currently bring written to /root in sysrescd's file system which is currently (I assume) in RAM. If I copy it to a USB stick, I assume I can resume the copy if I interrupt it now—but am I correct in believing that if I mount and CHKDSK the image in its current state, I won't then be able to resume the copy even with the logfile because the target disk has been modified? Many thanks for any assistance you can provide, and apologies if my mailer hasn't sent this in plaintext, I have limited options atm. Thanks, Jessica
_______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
