The drawback with Photorec is that all the metadata is lost, it just looks for file signatures and extracts files on the fly, naming them after the number of the 1st sector they occupy. All the directory structures, all the original file names, all the timestamps and other attributes, are lost. And in case of fragmentation, there's little chance that it will assemble all fragments in one single file (it does attempt to but with a rudimentary method, only works in very simple cases, e.g. if a file has just two chunks separated by another non-fragmented file), so fragmented files would end up truncated, thus partially or totally unreadable, even if all their sectors are still readable from the source.
So, if at all possible, use something like ddrescue, in conjunction with
ddr_utilities : with ddru_ntfsbitmap (part of ddr_utilities) you can create a mapfile which will set ddrescue to exclude the empty sectors from the clone, based on the $Bitmap system file (huge time saving as well as strain saving on the HDD if it's far from full – if for instance you had 500GB of free space you will avoid spending precious minutes or hours or even days copying 500GB of zeroes or remnants from deleted files), and you can also attempt to extract the whole MFT first. The MFT (Master File Table) is a very important system file which contains all the metadata, i.e. the directory structures, file names, timestamps and so on. So, first get the whole MFT if at all possible – but don't insist too much if it contains many bad sectors, it could further wear a drive which is already in a very bad condition (likewise, if the bitmap file proves too hard to get don't insist and skip that step altogether – get what you can as quick as you can run, don't bother too much sorting out women and children, you'll count 'em once the rescue teams abandon and say no more can be done !
) ; then clone or image the drive, using the mapfile so as to restrict the copy to the currently allocated sectors.
Once it's finished, or once it becomes so excruciatingly slow that it's no longer worth the hassle, if you could recover the whole MFT, then using ddru_ntfsfindbad (also part of ddr_utility) with the logfile from ddrescue as input you can get a list of files containing sectors which couldn't be recovered, that way you can know what is truly lost (helps the grieving process...), sort out the important from the trivial stuff, and see if you can recover important files which have been corrupted, if for instance you happen to have them on a CD/DVD somewhere, or on a remote server, or if you copied them to a friend or family member, whatever...
You could also open the logfile in ddrescueview and make a screenshot (even as the clone is running : just make copy the logfile – it's a good idea anyway to copy it at regular intervals as it can sometimes get corrupted, HDDSuperClone does that automatically), post it here, it might help someone to make a more informed diagnostic and provide you specific recommandations.
Connecting both the source and destination in SATA or eSATA or at least USB 3 would certainly be preferable, but with so many bad sectors (FD59 = 64857 pending sectors, B0D = 2829 reallocated sectors) you'll be happy if you can reach 35MB/s anyway (which is the approximate maximum transfer rate in
USB 2.0), so, speed-wise, it's kind of a moot point. But I've read that USB controlers could pose problems of their own, when attempting to copy data from a failing HDD. Even if you only have a laptop computer with only USB 2.0 ports and only one SATA slot, you could remove its internal HDD (which is safer anyway), place the failing one in its SATA slot, and connect the destination HDD to a USB port, that should be more reliable – but it will be tricky if you have to do a power cycle, i.e., if the failing HDD stops responding and it's necessary to shut it down, then start it up again. If I remember correctly, HDDSuperClone has the ability to send the HDD a power cycle command (making it unnecessary to physically unplug it), but I haven't tried that, and I don't know if HDDSuperClone can run a copy with a mapfile generated by ddru_ntfsbitmap, or if it offers a similar functionality. The author of that tool is a member of that board, maybe he'll be able to provide you specific tips relevant to your particular case.
EDIT 1 : Sorry, I hadn't seen the “USB only PCB” bit of information. If that really is the case forget the last paragraph (but it may be useful in other situations).
EDIT 2 : Of course what I wrote above doesn't contradict Spildit's recommandations above, this is a very specific issue and I have no direct experience with it. My intervention was mainly a response to rogfanther's post :
In my opinion, yes, using usb in a slow computer, low on ram, that would increase the time.
As Frank observed from the smart logs you posted, the drive has problems. So after making the changes for the slow fix, you can try again the cloning ( preferrable ) or running photorec.