Re: [Bug-ddrescue] Better alternative switches

[Dennis Juhler Aagaard]

I second that. 

I have also found some weird small tips that might help you. If you are trying 
to rescue a 2,5” harddrive, these drives have sudden motion sensors inside 
them, i have found a tip to slowly move/tip the drive while its reading. It 
will make some clicking noise but just be slow when you move it. Look at the 
ddrescue stats (current rate) to see what direction and how you need to move it 
for it to begin read the drive faster. Its not all drives that respond to 
movement, but it doesn’t hurt to try, just be carefull.

Sometimes putting the drive on the side or upside down while running also 
helps. Gravity can have a positive effect to a drive.

Then there is the tip of keeping the drive cold, so at the moment if you are 
located in the northern hemisphere, put it in a plastic bag and put it outside 
the window. :-) or in the cooler. 

In very very rare occasions i have been successfull by slamming the drive down 
on the table while it was running to get some more data out of it, but that is 
for last resort when you have rescued most of the drive and its going on the 
last spins before dying. Do not do that as a first thing to do, because you can 
be sure that the drive fail rather quickly after a table slam. :-)

-Dennis


> On 12 Dec 2014, at 07:20, Florian Sedivy <address@hidden> wrote:
> 
> Hello John, 
> looks to me like most you can do is wait …
> 
> Just some tips from my experience on OS X:
> 
> If the drive still mounts, you should prevent it being mounted read-write or 
> being mounted at all. Changes during rescue can potentially invalidate your 
> image, and every access on a damaged drive can worsen its state. My favorite 
> tool for this is Disk-Arbitrator. 
> 
> In my testing, the maximum read speed from a raw /dev/rdisk device was 
> achieved using a cluster size of -c 256. This corresponds to 128KiB which is 
> also the recommended st_blksize=131072 reported by stat -s /dev/rdisk.. 
> 
> If you notice a drop in speed after the first error of a run, you might try 
> ddrescue 1.8's new option -O, --reopen-on-error. 
> 
> And finally, if you know something about the distribution of your data or of 
> the damaged areas on disk, you could experiment with reverse runs or limiting 
> the rescue domain. 
> 
> Greetings, 
> Florian 
> 
> Am 09.12.2014 um 09:27 schrieb John:
> 
>> ​I have never needed more than a basic invocation of ddrescue to do a
>> recovery. That's good but it's also bad since I don't know the tool as well
>> as I would like to.
>> 
>> Generally I have used:
>> /ddrescue -v /dev/disk1s3  MyDriveRecovery.dmg MyDriveRecovery.log
>> and I have been able to get most stuff back.
>> 
>> It was suggested I could get stuff off the drive faster if I used the raw
>> method so I used:
>> 
>> mac:ddrescue1.8
>> ​me​
>> $ sudo ./ddrescue -v /dev/rdisk2s3  /Volumes/My\ Passport\ Air/
>> ​Data​
>> .dmg
>> ​Data​
>> .log
>> 
>> 
>> 
>> About to copy an undefined number of Bytes from /dev/rdisk2s3 to
>> /Volumes/My Passport Air/
>> ​Data​
>> .dmg
>> 
>>   Starting positions: infile = 0 B,  outfile = 0 B
>> 
>>   Copy block size: 128 hard blocks
>> 
>> Hard block size: 512 bytes
>> 
>> Max_retries: 0
>> 
>> Direct: no    Sparse: no    Split: yes    Truncate: no
>> 
>> 
>> Press Ctrl-C to interrupt
>> 
>> Initial status (read from logfile)
>> 
>> rescued:    16555 MB,  errsize:    983 GB,  errors:       6
>> 
>> Current status
>> 
>> rescued:    18391 MB,  errsize:    981 GB,  current rate:     4608 B/s
>> 
>>  ipos:    18420 MB,   errors:   28137,    average rate:     5027 B/s
>> 
>>  opos:    18420 MB
>> ​This has been running for almost a week now without much more success. (It
>> kicked off with an error at 16.1Gb so I restarted it and it's just been
>> running).
>> 
>> Can anyone suggest a better approach. If I stop ddrescue the drive will
>> mount again and I can see a list of folders and the files within. I have
>> been looking for a controller card for the drive and have not been able to
>> locate one so I am just moving forward but very concerned about data
>> integrity by plowing forward. Any suggestions?
>> 
>> Thanks,
>> John
>> _______________________________________________
>> Bug-ddrescue mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-ddrescue
> 
> _______________________________________________
> Bug-ddrescue mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ddrescue