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.

Looking at the IDENT data posted I noticed 30 pending sectors. When I see that I immediately migrate away and then use Seatools to zero wipe a disk so that the controller can bring a spare sector into use. Ignoring pending sectors is not a wise course of action.

My old HGST 12TB disk has 5 corrected blocks and it is now stable. Zero wiping it shows no further changes so the disk is stable. I use Seatools to zero wipe disks which is a godsend on my studio. The disk is current empty as I have many other disks in my studio to work with. The old 12TB disk still has 100% of the helium it came with so I believe this disk still has lots of service left.

I am slowly resurrecting an old Asus gaming laptop that has dual 2.5" SATA ports so I can use this machine when I need a native SATA interface when a USB enclosure is not supported. This should be handy as some tools need a lower level API. Seatools can work with USB boxes suggesting the developer had several models to work with.

_________________
USB 3.5" enclosures are $19 USD postage paid from China, I own several

Thank you all for the advice, especially ora for the detailed instructions.

I have successfully executed the Patch Mod 02 procedure. I followed the instructions and everything went smoothly, with no strange noises from the drive or the PC (I also created rom.bin). The process is shown in the attached Fig. At the end, I entered q to exit the application and rebooted the PC.

After that, I started the disk cloning process again. Using the default settings, the warning message appeared once more: Error (attached Fig).

Then I went back into Clone Settings and set the Skip Threshold to 12000 ms (12 s).

I also realized that yesterday, during the 1% disk clone test, the bbc.bin file actually grew to 20 GB.

The situation is similar now—as seen in the latest Fig, after a few minutes of processing, the destination file (kopdiska.bin) has grown to 15.3 GB.

Since data is actively being cloned, I am ready to continue, though the projection shows it will take a few days. I would like to ask: can I press the "Stop" button in OpenSuperClone in the meantime to let the drive rest a bit (leaving the PC and the OpenSuperClone application running), and then—after about a 1-hour pause—press "Connect" and "Start"? Will the disk cloning resume from where it left off in this case? Or is it not recommended to pause the cloning midway, even if it takes 3 days?

Summary: I performed Patch Mod 02, but I don't notice any difference compared to yesterday's cloning behavior when I reached 1%; the speed seems to be the same. I will probably just continue, even if it goes slowly. Also, since around 15.3 GB of data has been cloned so far, are these real, usable data, or is it not guaranteed that anything actually useful has been read yet?

So, it is time to try applying the Mod 32 patch (Option 5 in the VSC menu), as the program suggested. The patching process is similar to the previous one, with one significant difference: after the program asks you to enter the word "DANGEROUS", it will ask whether you have applied the Mod 02 patch and power-cycled the hard drive (yes, after applying these patches, you need to power-cycle the hard drive by completely shutting down the computer (rather than just restarting it); this may be reason why the Mod 02 patch alone did not work), and then prompt you to enter the word "YES".

Before applying this patch, click the SMART button in the OpenSuperClone window again to see if anything has changed. Most likely, the number of sectors pending reallocation has exceeded 30 following our attempts to clone the hard drive; this may explains why applying only the Mod 02 patch did not solve the problem.
Yes, of course you can. You can turn off the computer completely or restart it whenever necessary. That is exactly what the project file is for - it saves your copying progress. There is no need to create a new project file and image file every time; simply go to the "File" menu and select "Open existing project" to load your project file and resume copying with your chosen settings. You will need to re-select the source hard drive and the destination each time, as the project file does not store these specific details. You must select an existing image as the destination, since the program will continue copying new data into it.
Let's use that image file then, since it contains the most copied data. Rename it to "fullimage.bin". Also, take the project file located in the "wdb" folder - the one named "bbc.bin" that is 100 KB in size - and rename it to "success" (without an extension). Then, continue the copying process using only these two files. By creating a new project and image each time, you are essentially generating half-empty files and re-copying the initial gigabytes of the hard drive.
You can pause the copying process, but I certainly wouldn't leave a hard drive in an unknown state copying for three days with a long timeout - that’s a sure way to destroy it; so, try resolving the slow response issue first by applying the Mod 32 patch. If that doesn't work, you'll have to extract the data using virtual mode and likely abandon the idea of ​​cloning the entire drive.
No, we only copied data from the very beginning of the drive, where the operating system files and some file system metadata are usually stored. The data you are looking for is highly unlikely to be there.

If you want to try extracting your data as quickly as possible, go to the "Drive" menu and select "Start Virtual Disk Driver". The program should report success. Next, click "Connect" in the bottom-left corner of the main window; in that same corner, select "Virtual Mode 3" - this mode is specifically designed for hard drives with slow response problem. Click the "Start" button and launch the DMDE utility. It will ask a lot of unnecessary questions upon startup, but once you reach the main window, select "/dev/sdv" from the right-hand pane - that is the drive you need. The program will then very slowly scan for partitions on your drive; once it finds them, open the partition containing the lost files, and a slow file system processing stage will begin. In theory, this should allow you to access the contents of the "C:" drive - which wouldn't open on your new laptop - where the lost files should be located. Using DMDE is a separate topic; let me know if you run into any difficulties or confusion. Note that the demo version does not allow you to recover entire folders, only individual files from within them.

Since there was no "Pause" button (or anything similar), I had doubts about whether I could stop and resume the cloning process, so this is very useful information that the process can indeed be stopped and continued. Yesterday, I started the process as a new project and named it kopdiska.bin. The current status is visible in the attached screenshot. The process takes about 15 hours; during this time, if I understand correctly, about 18% of the disk has been processed, which amounts to roughly 123 GB of collected data.

I monitored the process, everything went smoothly and quietly, and the PC ran with minimal fan speeds (which probably means the system did not overheat and the hardware was not under excessive stress). I am a bit in doubt: since it is working, should I let it run to the end, or should I stop the process and apply the Mod 32 patch? I will do as you advise. However, I will continue building on top of this kopdiska.bin file, which is now 129 GB (while I am writing this)—it also seems to me that the process is getting slightly faster hour by hour.

That’s up to you to decide. You can leave it as is, though you’ll just be wasting two days of time. The fact that over a hundred gigabytes copied without errors is a clear sign of a slow response issue; no further diagnostics are needed. Alternatively, you can stop the copy process, apply the patch, and then resume copying - now you know how. Applying the patch certainly won't make things any worse. If, for some reason, the copying speed does not increase, you will have to continue copying as is.

Personally, I would apply the patch simply because, at high speeds, if the hard drive does have defects, the program's script will quickly skip those areas instead of spending a long time trying to read data that is unreadable - thereby avoiding unnecessary risk.