bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] Recovery Advice - Slow + High Error Rate


From: Felix Ehlermann
Subject: Re: [Bug-ddrescue] Recovery Advice - Slow + High Error Rate
Date: Sat, 19 Oct 2013 21:52:35 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Hi Niklas,

here's my personal experience on the topics you asked about. Maybe someone else on the list can share theirs.

> Q1 - can I speed this up some more"

If only a certain area of the disk is damaged you can speed up recovery by doing the recovery of the undamaged areas first.
The most simple approach would be to start at an arbitrary offset (e.g. 50G, 200G or 1T into the disk) and see if you get better speed there.
This will of course not reduce the overall time, but maybe you can get a major part of the data recoverd quickly and then deal with the pending (slow) areas at a later time.

Depending on what kind of defect the disk is suffering from (for example only one of the platters or heads could be damaged) you might be able to find a periodic pattern of "good" and "bad" areas.
The log file will tell you where the readable and unreadable parts are in the already processed part of the disk. If you can predict the pattern you can adjust the logfile accordingly, so ddrescue will read these areas during one of the later phases -> you will get the good areas recovered faster this way.
There was also an interesting discussion on this list a few weeks ago regarding the risk of further damaging a disk when spending too many read attempts on bad sectors - you might want to read up on that (Subject was "SMART, reallocation, and retries").

Regarding performance in general:
I usually get transfer rates > 50 MByte/s on the undamaged parts of disks with only a few (<10k) bad sectors.
The system I use is an older Core2Quad box at ~2.4 GHz, running a 2.6 kernel. The bad drive is connected directly via sata and the destination is usually an image file (either on local ext file system or on a NFS share).


>  Q2 - 10gigs in, I have 309mb of damage - is that a lot of damage? how badly damaged is this disk?

This is quite a lot of damage from my experience.
~3% of your drive is unreadable - if you know the average size of your files on the disk you can do some math to estimate how many undamaged files you should be able to recover from it.


> should I just accept its dead and not spend 2 months trying to recover it.

I think that is something you need to decide yourself.
However if the unreadable parts occur in short intervals and you got only large files stored on the disk you might and up with no undamaged files anyway.

You could take a look at the already recovered data - however as you're writing to a disk it might be a bit more complicated.
I usually would recover to an image. If that's not possible a disk which was zeroed prior to the recovery could be an option.
If your target disk was not zeroed and did already contain data when you started the rescue you could still create a "clean" image file by using the fill mode of ddrescue.


Kind Regards
Felix

On 18.10.2013 07:29, Niklas Swan wrote:

Hi guys,

this isnt a bug as such, but I've spent time tying to find the right forum to get advice about GNU DD-rescue, and this seems to be the only avenue.

I've spent quite a bit of time learning about how DDrescue works, but I need advice on the following topics with my current recovery, and what I can do to speed it up if possible.

ok, so when I started it was going very slow, like, only bytes or maybe a few kb. then I changed the script a bit:

 

sudo ddrescue -f -n -c 1Ki  /dev/rdisk1 /dev/rdisk2 nsclone.log

 

which sped it up a bit:

 

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...

 

but compared to other people who I hear about getting 20mg average, this is really slow.

 

so Q1 - can I speed this up some more"

 

Q2 - 10gigs in, I have 309mb of damage - is that a lot of damage? how badly damaged is this disk?

 

I did manage to get a few key things off it before starting this process, as it still ran but had errors.

 

Any advice on how to make the process faster, or on how damaged the disk is - i.e should I just accept its dead and not spend 2 months trying to recover it.


any expert advice would be really great, I can deal with a 75 day recovery if I have to, just want to make sure I'm doing it the right way.

Thanks, and apologies as this isn't technically a bug report.

really awesome utility tho! 

niklas


_______________________________________________
Bug-ddrescue mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ddrescue


reply via email to

[Prev in Thread] Current Thread [Next in Thread]