Niklas Swan <[email protected]> wrote: > sudo ddrescue -f -n -c 1Ki /dev/rdisk1 /dev/rdisk2 nsclone.log > > rescued: 9678 MB, errsize: 309 MB, current rate: 47662 B/s > ipos: 9988 MB, errors: 644, average rate: 102 kB/s > opos: 9988 MB, time since last successful read: 0 s > Copying non-tried blocks...
Scott is right that you should not worry too much about your error size, because it is mostly just the number of errors (644) multiplied by your copy block size (512Bx1Ki). In the best case this translates to 1 damaged sector per error, which would be only 300KB of error on the first 10GB - and this is still just the first run. As for copy speed, -d has no effect on OS X. You did the right thing already by using /dev/rdisk1 instead of /dev/disk and by setting -c 1Ki. You might experiment with even bigger copy block sizes (2, 4, 8, 16 Ki), but in my testing 1Ki gave the best results. Jumping further into the disk with -i 100Gi or more like Felix suggested can give you a better estimate for your total rescue time. You can somewhat automate that with the new option -a, --min-read-rate=<bytes>, that makes ddrescue jump forward when the speed gets too low. Something like -a 1Mi would probably quickly scan the drive for good areas in a first run. If you cannot get good speeds on any part of the disk, you might want to check your connection. If you can, put a known good disk where the damaged one is now and test with something like ddrescue -n -c 1Ki -f /dev/rdisk1 /dev/null which should give you a good estimate of the maximum speed to expect. Greetings, Florian
_______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
