Hi,

I am trying to rescue a large harddisk (1TB) by making an image with ddrescue.
As suggested on this page:
http://www.cgsecurity.org/wiki/Damaged_Hard_Disk
I started off with:
./ddrescue -n /dev/old_disk /dev/new_disk rescued.log

Now the program was running at like 30 Mb/s, but the speed keeps decreasing. Now after over 30 hours, its only at 330GB, and the transferrate is at 1.7Mb/s - still getting lower and lower all the time.

Why does it keep getting slower? Is there anything I can do ti speed it up? I also tried interrupting and then restarting it with the --block-size=4KiB parameter that didn't change anything. The transferrate remains.

Any ideas?

Thanks

Why don't you run it with the verbose option flag ?
If the disk has problems then the read rate will go down as errors are found.

What [s]he said ...
If it's a dodgy disk, what does time matter ?

It's probably dieing slowly. It will eventually reach 0, and then it will be dead. (except maybe for the freezer hack, which is a last resort)

Never had the freezer trick work. But, I'm anal about backups ...

Get kicked in the balls often enough, you take notice ...

As for the verbose option: I have enabled it now but so far there hasnt been any more output than without verbose (except for some lines right at the start). Also I haven't had any errors for quite a while, and so far only like 60 MB have been tagged as errorneous. So I'm kind of doubting that the slowdown is due to errors -- also note that the slowdown is slow, but steady -- if it was due to errors, i wouldnt expect a steady slowdown.

As for why time matters: Well I don't care if it takes a day, or a few days... but if it gets well below 1MB/s which is going to be very soon if the slowdown continues, its going to take weeks of even longer -- if its gonna finish at all.

I'm also kind of doubting the disk is really dieing - it looks like there was something in ddrescue that makes the speed degrade for huge files.

Oh by the way I found someone who appeared to have the same problem some time: http://www.mail-archive.com/bug-ddre.../msg00365.html Unfortunately noone replied :/

The speed will not degrade for huge files, in fact the opposite is true. Lots of small files take longer because the process keeps getting interrupted, and so it cannot build up to full speed.

Well I was talking about the size of the destination image file of course.

Status update: 411Gb now and it is down to 100 kb/s If i just restart the process and make it write to another file, it starts off with the full 30MB/s again and then starts dropping again

I've always had the same issue with ddrescue, I'm a computer tech and use it all the time for backing up data for customer's when the drive is either failing or they have accidentally deleted files and I need to recover their files or partition. I am currently backing up a 320 GB HDD that I know is not failing, I'm just recovering data on it. It started off at a decent speed but now it's done 220 GB after for running for 2 days and is copying at 390 kB/s. I know ddrescue will slow down when it's trying to copy bad blocks, but this is not the first time I've had it progressively get slower on a perfectly good drive, so I know it's not the drive.

Just wanted to let Dtag know you're not crazy.

Still searching for an answer to this issue.

Running Ubuntu 10.10, ddrescue 1.14

i would use larger blocksize, for eg 256K.
perhaps its heating up. try to keep it as cool as possible.

if all else fails, backup it piece by piece, by skipping some blocks on input and output (btw, be careful with that option, always remember block size)

A random note: if both devices are dangling of the same usb channel
that may cause issues; have you tried writing the output to a file
on the built-in HDD and compare the speeds?

And then see how it goes writing from that intermediate file to
the clone disk.

That's because it's a busted myth. It doesn't apply to modern drives.


Could try dd_rescue? From the README: You can tell dd_rescue to start from the end of a file and move backwards and it uses two block sizes, a large (soft) block size and a small (hard) block size. In case of errors, the size falls back to the small one and is promoted again after a while without errors.


Good point. I usually took source disks out, favoring a HW write blocker / reader or motherboard connection over whatever an enclosure provided.

Thanks


It's been a while since I had that problem -- I didn't really solve it. I only found out that ddrescue had an option to attempt to read the filesystem and it actually worked! I was really quite surprised as mounting previously failed with horrible error messages and everything seemed very broken and all my attempts to fix it failed. I then proceeded to copy the files over (which only took like a day). Some files are broken but like 95% are ok - that was fine with me.

Good to hear it worked out.

As far as the speed issue I believe (at least for me) it was a hardware configuration issue (device or driver). With the same machine I had a very similar slowing transfer issue with rsync but after reloading Ubuntu it has still had issues and now with ddrescue as well.

The configuration I use is a storage drive hooked up to a motherboard sata port and then the drive to a sata card. I hooked the drive up the same way to a different machine and resumed ddrescue with the log where the other computer had left off while running slow and the rest of the transfer went quickly.

So my recommendation for those having this issue is try a different machine and/or hardware. Wish I knew exactly what caused it though.

Sorry for resurrecting an old thread, but as this is the only time I've heard someone mention that ddresuce could be set to what sounds like a filecopy mode, I wanted to ask if anyone could clarify. to my knowledge and a scan of the ddrescue manual, I thought it only did raw disk or partition copies. I'm recovering a failing drive with only 40GiB of non-consolidated data spread over a ~240GiB disk. so I'm waiting a long time for ddrescue to copy good but empty sectors. The filesystem mounts fine, but the drive goes nonresponsive after repeatedly hitting a bad sector as file copy tools like to do (even HBCD's unstoppable copy proved quite a hands-on chore). ddrescue plays very nicely with the drive, but being able to restrict to used sectors would be a godsend... (drive frequently drops to <100k/sec)