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.

I have now left the cloning process running untouched for three days; it proceeded smoothly and quietly without any issues (process details are shown in the first image). As I understand it, this was Phase 1, the fast transfer of unproblematic parts—573 GB are on a separate, healthy disk.

Only a few percent were left, after which the process moved to Phase 2. Here, it has once again displayed a projection that it will take 10 hours to transfer these remaining 3% (the updated projection is now another 2 days). It is now likely dealing with the problematic sectors of the drive, so it is running slower. The PC is also running at higher RPMs now and seems more hardware-heavy loaded. Therefore, I'll let it run for 4 hours and then pause it for about an hour to let the equipment cool down a bit. Phases 3 and 4 will probably follow. Could you assess what the current situation is? If it's going to take another two days, I can manage this time frame with monitoring. However, I am considering 'patch mod 32' to see if it makes sense to apply it at this stage, since I've made it this far—up to Phase 2—without this fix.

If you're about to stop the copy process, you can try opening the disk image in DMDE and see if the data you need has already been copied. Be careful, though - the program will recover the files, but they could be damaged or empty, so be sure to check them all. Most of this remaining 3% of data is the first 15 gigabytes, which the script skipped at the very beginning of the copy due to the timeout being too low. This data has already been copied to another image, but it need to be copied again.

The slow speed is due to the fact that the read process is backwards. You can uncheck all the options except phase 3 in the cloning settings; the process will resume at the same speed as before.

Applying the patch is probably pointless now; the 15 missing gigabytes would have been copied in about 2 hours in phase 3, leaving perhaps up to a hundred megabytes uncopied, most of which are file system structures and Windows files. But you can go this route instead of skipping phase 2, and the process should go even faster.

I have now finished the cloning process. Following the advice, I switched from Phase 2 to Phase 3, but the situation was similar—processing the remaining 1.5% of the disk (approx. 10 GB of data) showed a projection of 2 to 3 days. I also monitored the size of the cloned disk image, and even though the processing of the remaining data went from 3% down to 2% and finally to 1.5%, the size of the kopdiska.bin file no longer changed (increased)—see the attached Fig. I assume that this remaining ~10 GB might just be unallocated/empty space on the disk. If necessary, those 10 GB could probably be cloned separately.

So, I then installed the DMDE 4.4.4 free version on my primary Windows PC and connected the USB drive containing the cloned disk. I ran a Full Scan, and the results are shown in the pictures. One of the partitions looks like it should be completely fine, as all the original files are visible as they were. For the other partition, DMDE sorted the files by document type, images, etc. I checked the JPEG and TIFF images, and it looks like I can preview most of them; some don't open, and some open only halfway. Overall, if it stays like this, it will already be very good—I've already found some of the key images.

However, I'm not sure how to best proceed from here. I think there was a 'Recovery' button which I haven't tried yet; what was shown in the pictures was just the result of the Full Scan command. Will the Recovery function try to put things back into their original folder structure? Well, even if the images end up being listed randomly one after another, it won't be a big deal.

By the way, the original damaged drive survived—between Phase 2 and 3 the PC was running at a slightly higher load, but everything went fine. To get those last 10 GB, I probably would have had to push it for another 2 to 3 days, and it's questionable whether it would have had any effect on the data, because as mentioned, the .bin clone file was no longer growing with the processed data amount.

So it looks like it wasn't all in vain—thanks ora for all the guidance!

I have looked over the saga here and I see using this antique hard disk for far above its design life is why errors are festering away. SSD have replaced SATA hard disks more than a decade ago. Now M.2 is the latest move which surfaced again more than a decade ago.

The Asus ROG machine has a M.2 slot but it is only ACPI. Instead when I used dual SATA SSD the machine was a lot better than OEM 320GB it came with. AFAIK the OEM hard disk is still in the box along with lots of others. My old Asus machine has a BD drive in it. Recently I ran across a NVMe BIOS for the machine but I have dual SATA SSD in the machine.

Now I have seen tons of SATA SSD that have endured all manor of faults. The moral of the story, make a backup.

I have used a USB UHD BD drive for maybe 5 years and with 50GB dual layer discs, I can make backups to optical disks which are less likely to croak. CD albums are perfect for storing CDR, DVDR, BDR and so on. Sometimes I migrate old DVD backups to BD25 or BD50 depending on which spindle is in stock.

Yes even optical drives can fail. This is why I bring up redundant backups. I have an old Lenovo USB DVD drive that still works.

Now revisiting the old 640GB hard disk. With 30 known uncorrected blocks tells me the disk is far past viability These can lead to errors the fester away. CHKDSK /R can map out bad blocks but hardly anyone thinks that way.

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

We're honored, thank you!

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

The NTFS metadata for $NoName 02 are damaged,so DMDE is resorting to file carving.

If you open the .bin image with 7Zip, are you able to extract the good NTFS volume? You may need to change the .bin extension to .img.

_________________
A backup a day keeps DR away.

To get around the problem with slow copying, you can make phase 3 somewhat similar to phase 1 - in the cloning settings, increase the "Cluster size (LBA)" from 128 to 256, 512, 1024, 2048, 4096, and so on, checking whether the data is actually copied and not skipped. Since the hard drive has a problem with slow response, with the current cluster size (64 kilobytes), it returns that much data for every data request, which lasts up to several seconds. Hence the low speed. In the first two phases, the script automatically begins to request more and more data if the hard drive successfully reads it; after phase 4, the script will begin to request one sector (half a kilobyte) per request.
This is how it should be - it shouldn't grow, as soon as during the first phase the script reaches the last kilobyte on the hard drive, the file can no longer become larger, it will be equal to the capacity of the hard drive (~640 billion bytes). Uncopied data are zeros inside the file itself; the script will overwrite them with real data as soon as they are copied.
No, this is the beginning of the hard drive - there will always be real data here. The only exception is when there was a deliberate attempt to erase the hard drive. The problem that you encountered in DMDE was precisely due to the fact that parts of the file system metadata were not copied, so the damaged partition does not open, and you see only those files that were found by searching for file signatures, but there are no folders and files. Files on the hard drive are not always written continuously, and information about where parts of the files are stored is recorded in the file system data, so in order to successfully copy those images that have been partially opened, you will have to continue copying the hard drive.

You can also try R-studio and scan the damaged partition in the image file. R-Studio usually copes somewhat better in such cases. Do not scan the entire image, this is a waste of time, and in DMDE this is also a source of problems, because this program mixes everything it finds on all partitions into one pile, both folders and all files.

But as soon as you copy the hard drive completely, DMDE will be able to open the partition without a full scan at all, and most files, if not all, can be recovered without errors.

You can, of course, create a new project (with an increased timeout, of course) and a new image and copy the first 20 gigabytes into it, which won't hurt, but then there will be a problem with merging the two image files into one complete one. This is a highly unusual task, and there is no program to solve it. Unfortunately, in opensuperclone there is no option to restart an arbitrary phase for uncopied data, this would be very helpful in the current situation.

Yes, things are moving in the right direction. I've now done some research on these data recovery programs; DMDE already found the vast majority of things last time—true, the files were randomly named, but hey, the data is here! Then I thought, what the hell, let's try R-Studio as well. Total shock, the code recovers things with proper structure, you wouldn't believe it. At first, I checked everything, and it even started recovering old files from the Recycle Bin from years ago that I had deleted long ago. The estimated recovery time for everything, including Program Files, Windows, Temps, etc., was around 5 days. Then I stopped it and, obviously, selected only experimental and personal data (the rest is system data), and now the process is running (see attached images).

So, fantastic applications: OpenSuperClone (an additional setting: Skip Threshold set to 12000ms helped a lot in my case), DMDE is also super code, and R-Studio looks like it will provide the finishing touch.

I also tried 7-Zip as advised, and it really does separate the partitions (attached image), but R-Studio is a truly powerful tool—you just run a full disk scan and select what you want it to recover (DMDE probably has something similar).

This has definitely been a great lesson for the future; hard drives and USBs are really affordable with large capacities, and I've already bought a few units for data backups.

Once the recovery is done, I'll check if everything is in place. Considering that about 10 GB of data was left over during cloning, I will try the additional settings in OpenSuperClone as ora advised, just in case.

If I have time, I'll compare whether both programs recover the specific images.

DMDE can do this too, it's just that it's a very specific program with a focus on professional data recovery and it has a unique, confusing interface, not like regular file recovery programs.

To see the folders and files in it, there are two ways: open the partition in the "partitions" tab, and run a full scan of the partition if the necessary files and folders are not found. Or scan the entire image, after which the "full scan" tab will appear and in it you need to open "NTFS 2", which was offered in the main results. In any of the methods, after completing the process, a "more/less results" button will appear in the tab with the open partition at the bottom left. You click on it, click on the "++" button next to the green stripe once and click OK, after which a miracle will also happen. R-Studio does not have such settings, and after scanning it will immediately show everything it found.
You fell into the first trap. The program will actually show "files" that were deleted many years ago, but these files are no longer there. These were some fragments of old file records, and the place to which the file record points, and where the deleted file once was, has already been overwritten a hundred times with new data. Try to restore several of these files, none of them will open.

And there’s also a second trap waiting for you, which you also fell into when the program reported that the files had the same names and asked what to do. Whether in DMDE or R-Studio, look at what is in the folders and an interesting surprise awaits you - the files are repeated several times. Although this supposedly cannot be true - you cannot save a file with the same name several times in the same folder, this is absurd. However, for some reason this happened. And this happens because the computer in the background is engaged in various optimizations of the file system and data on the disk (organizing, defragmentation) and every time something is done with a file, new file entries appear. This also happens when you open a file, edit it, and then save it.

It may seem that this problem can be ignored, but no, it cannot. Recover all the duplicates of one file, just let the program automatically rename them rather than overwrite them, and you will see that one of these duplicates opens as expected, while the others either open partially or, most often, are completely damaged. Now you have a new entertainment: manually sort through the recovered data, deleting damaged files. And there may be 10-12 duplicates, this usually happens with documents. In R-Studio there are yellow and green dots after the file name, which can tell you what to choose, and in DMDE this is an icon of torn paper and paper with a green arrow in the upper left corner to the left of the file name. But under no circumstances should these tips be blindly trusted.

You can save yourself from this problem, and also save these programs from having to scan the entire partition and restore the damaged file system from parts of the secondary data - simply by copying the missing data. Windows will not be able to open or restore a relatively intact but damaged file system, but for these programs this situation is not a problem at all. But when a piece of the file system simply does not exist, then this is a difficult task even for these programs.

What to do is also up to you, if there is not much important data left and it can be parsed manually, then you can go this way.

There is a third trap, which you also saw - damaged files. In camera photos, there is a thumbnail image at the very beginning of the file. In Windows Explorer you will open a folder with photos, these thumbnails will be read, and it may seem as if everything has been restored. But as soon as you open the photo, a surprise may happen - half of the image is missing. It’s the same with archives - they can open, but unpacking will fail. It's the same with videos and music - they can play, but not completely. Be sure to check the recovered data, since these programs do not check the integrity of the files. Don't rush to restore your data, delete the image file, or throw away your old hard drive.

And there remains a fourth trap - parts of some files may be among those uncopied 10 gigabytes. These files can only be detected using virtual mode in opensuperclone and using DMDE there. When working under Windows, these files will be restored without errors with empty data inside. This problem is solved in the same way as the previous one - copy the remaining data.

-------

P.S. DMDE also has a surprise in the file recovery window - there you can choose whether to recover deleted or non-deleted files. What the program considers deleted can be understood by the trash can icon next to the name of the file or folder. If all the files in a folder are selected, but in this window, for example, deleted files are not marked, and there were such files in the folder, you will be in for an unpleasant surprise - supposedly everything has been restored, but not everything, and you may miss it.

You need to get used to this program and have experience using it, it is truly unique.