Re: [Bug-ddrescue] DDrescue - assistance

[Fourie, Craig (Technical Resolution Team)]

All

We are writing to a totally different vv
With different physical drives so it won't write to anything impacted. 
Unfortunately we have tried what you mentioned. Your call of course Adel but 
I'm not sure if we will benefit in this case

Antionio. Thanks for your help so far . 

Regards

Craig

Sent from my iPhone

> On Sep 8, 2017, at 11:27 AM, Antonio Diaz Diaz <address@hidden> wrote:
> 
> Hello Adel,
> 
> Majed, Adel wrote:
>> Please find feedback on your question from our HP support team
> 
> Thanks.
> 
>> Q1: Why are you running ddrescue in reverse mode (backwards)? Reverse
>> mode is usually slower
>> 
>> When the script was initiated, it was throwing error and we could not
>> proceed with the VV recovery:
>> 
>> ipos: 37375 MB, non-trimmed: 131072 B, current rate: 63504 kB/s
>> opos: 37375 MB, non-scraped: 0 B, average rate: 75352 kB/s
>> non-tried: 10957 GB, errsize: 0 B, run time: 8m 16s
>> rescued: 37374 MB, errors: 0, remaining time: 1d 16h
>> percent rescued: 0.33% time since last successful read: 0s
>> Copying non-tried blocks... Pass 1 (forwards)
>> ddrescue: Write error: Input/output error
>> Hence the '-R option' was used. Which seems to be working fine.
>> 
>> Q2: What command line are you using to invoke ddrescue?
>> 
>> ./ddrescue -f -n -R /dev/tpddev/vv/52 /dev/tpddev/vv/27917 
>> /common/support/vv52_new.log
> 
> From the above it seems that you are writing the copy to the same 3PAR array 
> where the volume that you are recovering resides. In which case, the write 
> error is probably caused by ddrescue trying to write data to the same failing 
> physical disk(s) it is reading data from, and a new write error may happen at 
> any moment.
> 
> If this is the case, I recommend you to:
>  1) stop ddrescue (pressing Control-C).
>  2) copy /dev/tpddev/vv/27917 to a safe place (free from failing disks). 
> Either a different array or a suitable physical disk.
>  3) run ddrescue again without the -R option, using the safe copy of 
> /dev/tpddev/vv/27917 as destination, and the same mapfile:
> 
> ./ddrescue -f -n /dev/tpddev/vv/52 <safe_destination> 
> /common/support/vv52_new.log
> 
> If you do it this way, and the volume can sustain the average rate of your 
> first forward run, the first pass of the rescue may be finished in less than 
> one day.
> 
> The bad news is that there are 102891 read errors more or less evenly spread 
> across a large part of the volume being rescued. Just 2 contiguous good areas 
> are larger than 500 MB. Recovering the last 10% of the volume is going to 
> take a long time (weeks or months).
> 
> 
>> We have a log files that is saved under /common/support/vv52_new.log
>> Attached it here.
> 
> Remember to always run ddrescue using the same mapfile, so that it can 
> continue the rescue where it stopped. Also verify that the mapfile is written 
> to a safe place. Keeping the mapfile safe is very important in large rescues 
> like this one.
> 
> NOTE: In versions of ddrescue prior to 1.20 the mapfile was called
> 'logfile'. The format is the same; only the name has changed.
> 
> 
> Best regards,
> Antonio.