I think you're beating the drive to death...

It seems OP is giving up on the data anyway.. Who am I to argue.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

After a somewhat longer absence, I’ve recently tried the suggested steps. I reconnected the faulty drive to the Windows system and attempted to use the Victoria 537 application. Unfortunately, even after waiting for an extended period, the drive did not show up in Victoria (the app remained constantly in a "Not Responding" state, and I waited for as long as 30 minutes).

Next, I tested the approach suggested by ora. I switched back to OpenSuperClone and reinstalled the faulty drive internally via direct SATA into the old laptop.

I attempted the drive cloning process again, this time adjusting the Skip Threshold to 12000 ms (12 s) in the Clone Settings.

Observation: This time, the cloning process did not freeze, but it is quite slow. I ran a test run for about 1 hour (and then pressed STOP). During this time—if I am reading the process parameters correctly from the attached figure—about 1% of the data was processed. Around 8.63 GB of the drive was parsed/scanned, but only 119.4 KiB of data was actually written to bbc.bin (my chosen image file name).

So, after running the cloning system for a 1-hour test, the process didn't halt, but shouldn't there be roughly 7 GB of actual copied data in the bbc.bin file by now?

As some of you have already pointed out, the issue is very likely the Slow Response Bug.

It seems we are slowly moving towards executing the step: Patch Mod 02 (and possibly Patch Mod 32), as mentioned by ora and fzabkar. From what I have gathered in the available documentation, the software makes a minimal modification to the drive's firmware to "unlock" the copy process, allowing the drive to read without getting stuck in error-handling loops.

As I mentioned earlier, I will be cloning the entire contents of the faulty drive onto a new healthy drive via a USB 2.0 connection (there is no other option). Since USB 2.0 is already quite slow, applying this patch would hopefully allow us to extract the data in the shortest possible time with minimal "Slow Response" delays.

If the experts on this forum confirm that proceeding with Patch Mod 02 makes sense at this point, I would like to double-check the exact step-by-step procedure with you once more (I previously prepared a list of steps).

You’d better watch this video to see what it looks like. I used a hard drive from the same family as yours to verify that this procedure works. Yes, it works and won't cause any damage. Since the hard drive will still suffer from slow response throughout this process, everything will happen much more slowly than in the video.

https://streamable.com/coz5el

After the lines "data verified" "disable vsc" simply turn the laptop off and on again and resume copying - now at high speed.

Before applying the patch (option 2), copy the module files from your home folder to the new hard drive. You almost certainly won't need them, but it's best to make a copy anyway.
Check carefully where you saved the project file and the image file And it's better to give the image file and the project file different names - you've already mixed them up You saved the image file in the root folder of the new hard drive; it will be either 8 GB or the full 640 GB, depending on whether you ran an analysis before cloning. The project file, however, was saved in the "wdb" folder and should be no more than a few megabytes in size.

I don't know why the USB 3.0 port on your laptop isn't working - it should, since Linux comes with a universal driver - but even if it were working, under ideal conditions, your drive would copy data only twice as fast as it would via USB 2.0.

In reality, this patch doesn't do anything monumental. Module 02 is a hard drive configuration file that defines the drive's capabilities and behavior; the patch simply disables functions related to handling problematic sectors. It doesn't introduce any major changes - the functionality itself was built in by the manufacturer - but these specific modifications aren't intended for end-users to perform. Module 32 is the file where the drive lists unreadable sectors; patching this module simply clears the list, which is necessary when the drive starts freezing while processing an excessive number of entries.

There is nothing truly dangerous in these patches; they are standard actions that are performed when data needs to be recovered from a hard drive that is difficult to read. The main threat is that if a patched file is written with an error, the drive may refuse to return to a ready state, and everything will have to be restored to its original state, which requires experience and different software. And if a hard drive has damaged heads and can no longer write but can still read, then writing a patched file to the system area would cause major problems - but that is not the case here at all.