HDDSuperClone
- Thread starter maximus
- Start date
And you are going to wait a little bit longer for that now. This is a bit of a setback. I was planning on doing some drive cloning/swapping to improve my test system and get a second system up and running, and now I am going to be a drive shorter than planned, plus I am tying up the drive I am cloning to and the OS drive. And I had just received my new 4-relay boards a couple days before this too, now they are just sitting there waiting for me to play with them...Jared":1s81lqln said:
On the plus side, this "test" has shown a small bug that happens in the log file that I have to figure out. As far as I can tell I don't think it is going to affect the recovery, as it is just a matter of two lines in a row that have the same status that should have been merged, and can be merged again by the built in log repair feature. If I end up spending days on this and it turns out to be messed up I will be very unhappy.
It is up to 96.6% recovered now. I am doing things that I did not intend to be done. The skipping algorithm worked great, but hitting the third pass without skipping was not working out very well for this case. So I am using the options to do more controlled skipping on the last of the untried areas that have already been skipped. I can provide the tool and it does help that I understand it best because I wrote it, but there is no way I can teach someone how to do something like this. I am making judgement calls on the fly to see what works best for this drive.
The drive recovery is up to 97.79 percent, and I am calling it quits. According to my calculations, the rest would take a few months. I think I will run my ntfsfindbad on the clone and see what files are worth keeping from the recovery attempt. Some of the files that I was hoping to keep are large and are most likely corrupt. Bummer. Oh well, no super critical data lost. Time to move forward again.
That is a matter of perspective. For a personal recovery, that could mean getting most of the important documents, pictures, videos, and other. Some pictures can handle a bad spot and still look okay, videos can usually handle small bad spots and still be okay, documents are usually small enough that they are either recovered or not. But what if the data is larger files that can be considered corrupt and useless / untrustworthy if they are not 100% intact, such as an image file or a virtual machine. A bad head can span across the entire drive with lots of small errors, maybe only one sector in size each. Many small files can be recovered 100%, but larger files are subject to likely corruption. If the desired files to be recovered are large in nature and need to be 100%, then a case like this is not a success.pclab":350dbd5c said:
Yes, statistically this is a good recovery. And I am getting many good files from it, I think. Just not the large ones. My ntfsfindbad showed almost of the bad files were ones I did not care about. But it is flawed, as I found that it was not reporting on the larger files (this is caused by an issue where the data run info is not directly in the MFT, and I did not address this issue yet). That also means that my custom software to recover individual files won't work on some of the files. So I broke down and did the inevitable. I bought R-Studio (the Linux version of course). Had to happen sooner or later. I also used the fill mode of ddresuce to mark the bad areas so I will be able to tell for sure if files are corrupt (not implemented in mine yet, there is a reason I mad it backwards compatible with ddrescue logs).jol":zsbzhkn2 said: