hard drive recovery - ddrescue very slow, writing to NTFS – is it worth it to convert to Ext4 now?

Two days ago I began the recovery of a 1TB failing HDD which was handed out to me with the hope that I could salvage most of it for a cheap price.

At first it behaved erratically, often being disconnected suddenly and making scary noises, with a copy speed varying between a few KB per second and about 50MB per second (it was a hot day, I tried to prevent it from overheating with a laptop cooling pad underneath and a cooling block over it, which I changed every hour or so). Then, during the first evening, it became more stable, but the average copy speed went down significantly, to around 3-4MB/s. Now, having recovered 250GB, I'm down to about 400KB/s on average, which is painfully slow (at least it doesn't seem to decline further).

So my questions are:

• I'm doing that recovery to a NTFS partition, which, from what I read quite late in the process (on this french guide), is not recommended as it might slow down the recovery considerably. Is that (still) true, and if so, why?
  
  
  
  • Or is this a thing of the past, when the NTFS driver for Linux wasn't mature enough? (I'm using the latest Knoppix live DVD, copied to a memory card as it wouldn't successfully boot from a DVD-RW.)
  
  
  
  


• Would it be worth the trouble to convert the partition to a native Linux format like Ext4 at this stage? I mean, would it significantly improve the copy speed?
  
  
  
  • Or is it normal to experience such a slowdown with a failing drive, after the first pass where most “healthy” sectors have already been recovered? (The SMART parameters are worsening, the “overall-health self-assessment test result” went from “PASSED” to “FAILED”, the number of reallocated sectors went from 144 to 1360.)
  
  
  
  


• Is there something else that I can do to improve the recovery ratio and/or recovery speed?


• Are there options in ddrescue which I could try with some real benefit?

I made the first runs with this command :

ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log

(The -n & -N switches supposedly bypass the scraping and trimming phases – although I'm not sure at what point in the process those actions are attempted by the program and if that is actually useful to bypass them. Then I specified a minimum copy speed of 500000 bytes per second, and a value of 1MB for “initial size to skip on read error”, attempting to copy as quickly as possible the areas which are still healthy or easy to access. The -u is for “unidirectional” : in a former recovery with another HDD, copying in reverse sense with the -R switch seemed to improve matters, but with this one it seems to wreak havoc, and it's apparently more stable with that switch.)

Now, after it completed one pass, I removed most of these parameters, only keeping the -u. I tried the -d switch at some point (“use direct disc access”), but then nothing was copied, the “error size” grew very quickly.