PCB BIOS and FLASH swap

[pepe]

yes, i got it, thanks. So the main point is that there are no green dots in the bad areas, so absolutely no data read from there. Question is how large the skips were, was the head skipped in one step or several ones, coz if in one step, then it's no wonder it does not have any green dots, if the skip was like 1024 sectors, then there should be some greens if the head is able to read. If there are no sectors read from the areas belonging to that head then it should be weak indeed and it may be recovered after a head swap, however i expect some surface damage there.

pepe

[maximus]

First, I don't have the most recent log, maybe that could be attached by the OP for reference.

In the latter recovery attempt, the settings were set for fast skipping, so only 3 to 4 reads per head section. So those 3 or 4 grey spots in each spot in the pattern were the read attempts. The rest of the black areas were skipped as non-tried. But to be fair, the latter recovery attempt was using timeouts to proceed, so a full long attempt to read was not being done. So if you wanted to argue that maybe it could read at a further point if it was let to do so without a timeout, then maybe that could be possible, although my opinion is that is not likely.

But early on in the recovery, before the pro version was being used, and even when the slow issue was still present, the read times were about 62 seconds in the bad head area, which is an indication of the OS performing the timeout at 60 seconds and doing its own reset. There were many more tightly close read attempts in the bad head, of which none read any data, and all were in the 60 second range. Also, I looked at the actual logs in text format to verify things, which I am sure no one else does, because I am probably the only one that can truly understand them. The format is explained in the user manual, but how many people would actually get that deep into it?

In the course of all of my learning, I have become very good at judging a log from my software. I will always be willing to help understand a log. But also know that when I say I see something, then I see it clearly, or at least as clearly as I can from the data given.

[zvit]

The only log file i saw was from the very beginning of your process, i might have missed a larger log?

Attached is the final log file, the scan from start to finish. maximus said that the green dots around the black area could very possibly extract more data around the head with a phase 2 scan.

Attachments

F_TAL_final-6-image.scn.txt

(11.66 MiB) Downloaded 790 times

[pepe]

@maximus:

yes, a log file is a good source of information, especially when you know exactly what's in there. Like error codes and the process that produced that file.
Since the map looks quite similar to the ones used in pc3k and its clones, first i tried to interpret it similarly but after a while i had to realize it is quite different so i needed some re-interpretation
Moreover, i know that it is quite hard if even possible to get information from behind the usb bridge and the kernel drivers. I think this is a major drawback of this process, however, i must admit it is remarkably efficient at the level of resources used.

@zvit: the data you may expect from the green dotted blacks is rather small in amount but not zero of course. I estimate it being less than 1%.

pepe

[maximus]

@zvit: There is something very wrong with that log file, as in it is not a log file at all, but something else.

As for the getting more data from phase 2, it is not just the green dots. There is data in the black non-tried that could still be read. It is at the trailing edge where the green dots are, but it can go farther back in. The head skipping algorithm tries its best to get as close as possible, but it can never get exact, even more so using the skip fast option. So it would have skipped past the edge of the bad head into the good area. That is why phase 2 is a compliment to phase 1, it catches that trailing egde data. Not running phase 2 means not reading the most good data from the good heads. It could mean the difference of some files being corrupt or being good. It is not a huge percent, but I would say more than 1%. I really can't say for sure how much data is left to be read though. An actual real log file would help me get an idea, but it is still impossible to tell for sure. I have never even tried to estimate something like that before. Actually in this case, 5 of 6 heads would be 83.333333 percent. How close to that total is the finished part? That would be the best way to tell how much data could still be read.

[zvit]

@zvit: There is something very wrong with that log file, as in it is not a log file at all, but something else.

Oooopss! That was the lof file from the R-Studio scan. Attached is the correct one.

Actually in this case, 5 of 6 heads would be 83.333333 percent. How close to that total is the finished part? That would be the best way to tell how much data could still be read.

She looked aver the drive and determined that most of her files are intact. 580GB of data. Many folders with pictures and videos will have a few images and a few videos that won't open but we're talking about 3-5%. Some of the corrupt files will be normal file size and some a few KB. I'd say that she got 85-90% back. Even 19GB (9K files) are almost all intact from the recycle bin. So in case she trashed an image similar to one that's corrupt and can use the trashed one. She was probably lucky that most of her data was written by the good heads.

She is already contempt with the results but as I mentioned before, for educational purposes, I will be doing the phase 2 scan when I get the SATA pcb. I am not sure if the USB relay that I also ordered should be used when using a SATA connection...? I will ask when I get to that stage.

I will also ask about the correct procedure to do phase 2 - if I should open the phase 1 project file, use the 1TB phase 1 image as the destination and only select phase 2 scan (and change the "finished" status) or if I should create a new project and select only phase 2.

Attachments

Final-6.txt

(504.44 KiB) Downloaded 774 times

[Lardman]

I will also ask about the correct procedure to do phase 2 - if I should open the phase 1 project file, use the 1TB phase 1 image as the destination and only select phase 2 scan (and change the "finished" status) or if I should create a new project and select only phase 2.

AFAIK phase 2 methodology is the same as phase 1 but reads in reverse (Maximus can confirm this) . Effectively grabbing data from both the left and right sides of the bad area, the theory being the bit in the middle left unread is dead / unreadable.

You add phase 2 data to phase 1 data - reading a drive backwards is much slower than forwards on overage here 120Mb/s forwards to 10Mb/s backwards. Open your project and deselect all phases and then add phase 2 back. If it says "completed" without scanning you may need to "reset current status" from the tools menu.

There's little point in converting to SATA to get more data , if you want to experiment with the drive to get more in these sort of situations you should be looking at learning to swap and/or clean heads SAFELY.

[zvit]

AFAIK phase 2 methodology is the same as phase 1 but reads in reverse (Maximus can confirm this).

Yes, maximum already mentioned this and it's explained on his website.

You add phase 2 data to phase 1 data - reading a drive backwards is much slower than forwards on overage here 120Mb/s forwards to 10Mb/s backwards.

Oh wow. I would have to get a dedicated spare computer for this. My phase 1 was reading 1TB at 80-90MB\s and took about 16 hours (actual scanning time - not reset time - which I'd reduce hopefully with a USB relay) so phase 2 would read only about 7MB\s which could take two weeks to scan! I'm confused though how others have commented here that a professional would have completed this recovery (without a head swap) in 24 hours! How is this possible if a full scan can take days or weeks?

There's little point in converting to SATA to get more data

The reasoning behind converting to SATA wasn't to get more data but to eliminate the resets, as I understood that the USB connection was causing this - did I misunderstand this? I thought that a USB relay is the next best choice for less resets and sata would be the best choice. The resets took more time than the scanning. Everyone here said that any professional's first step would be to convert to SATA. What would the reason for this be if not for speed?

if you want to experiment with the drive to get more in these sort of situations you should be looking at learning to swap and/or clean heads SAFELY.

I would do this if I was getting into the DR business as a full time job, but that's not my goal. There's a reason that many DR places that are looking for dr technicians, I've seen require at least 1000 head swaps to apply for a job!

[Lardman]

so phase 2 would read only about 7MB\s which could take two weeks to scan!

Nope - You only scan what wasn't scanned with phase 1 with phase 2, so you'd only be scanning 16% at most of the drive even if you scanned all the skips which you wouldn't be doing anyway, but yes at a much lower speed.

I'm confused though how others have commented here that a professional would have completed this recovery (without a head swap) in 24 hours! How is this possible if a full scan can take days or weeks?

You can't compare hddsuperclone @ $20 to pc3000, which is closer to $10,000. One is a software imager the other a DR hardware/software solution.

The reasoning behind converting to SATA wasn't to get more data but to eliminate the resets

The resets are because the drive is struggling to read (dead/weak/damaged head- whatever term you like) changing the method is reads by wont help it read but it changes the level of control you have over what happens when it can't.

Everyone here said that any professional's first step would be to convert to SATA. What would the reason for this be if not for speed?

See above - control .

[zvit]

Everyone here said that any professional's first step would be to convert to SATA. What would the reason for this be if not for speed?

See above - control .

But people were advising me to convert to sata even when they knew I was only using hddsuperclone. Why's that if I wouldn't have more control with sata anyway? (By control, do you mean like disabling a head completely or something like that?)

[maximus]

She is already contempt with the results but as I mentioned before, for educational purposes, I will be doing the phase 2 scan when I get the SATA pcb. I am not sure if the USB relay that I also ordered should be used when using a SATA connection...? I will ask when I get to that stage.

I will also ask about the correct procedure to do phase 2 - if I should open the phase 1 project file, use the 1TB phase 1 image as the destination and only select phase 2 scan (and change the "finished" status) or if I should create a new project and select only phase 2.

First, if the drive is encrypted by the USB bridge, then you can't just convert from USB to SATA and continue. You would have to start over with a new log and new image file, and then after getting as far as desired in the recovery, use something like reallymine to decrypt it. I don't know if your drive is encrypted, and I already asked this on here an no one responded.

Second, assuming no encryption, or using the same direct USB mode, you could disable phase 1 and enable phase 2 and continue. You should always use the same log and destination when continuing, although I do recommend making a backup of the log in case something does not go as expected.

[maximus]

The log shows 82.518059% finished. So with an expected recovery of 83.333333%, that leaves a possible 0.815274% of data that could be retrieved with phase 2. That doesn’t sound like much, but it would be a good 8GB of possible data. It also means that it was less than 1%, which means that the skipping algorithm did what it was designed to do. It also means that pepe was correct about it being less than 1%. @pepe, how did you know that when even I didn’t? I know you are good, but that was a psychic kind of good.

I would like to point out a flaw in the log, for anyone who looks at it. The skip run count is 52, and it should be about 1430. I think that is a bug in the software using the skip fast option, that I will look into and fix in the next release.

After phase 2 there would still be some edge data not read, which I calculate would be about 94MB. The cluster size was 128, in theory it would average in the middle of that for each edge, so combining both edges would be an average of 128 sectors missed per head section, there were about 1430 skip runs meaning 1430 head sections. 128*1430*512=93716480. It would be possible to get that data with another run of phase 1 and 2 with a cluster size of 1, but I would not see much benefit in that for the small amount of data vs the time spent.

As for phase 2 reading in reverse, and reading in reverse being much slower, that is correct. My experience is that reading in reverse is about 10 times slower. But with only 8GB of data to read in reverse, that would not be a significant amount of extra time, compared to how much time is being spent with the reads in the bad head needed for skipping. I would expect phase 2 to take about as much time as phase 1. Actually probably faster by about 2-3 hours because of the comparatively less data to be read.

Also, I did not see any data read in the “bad” head. The timer settings were such that it was given 4 seconds before any resets were sent, so it was given at least 4 seconds per read attempt. It also looks like the drive responded many times on its own without needing the reset, probably in the high 3 second mark because the total time took at least 4 seconds. Most of those returns were with a sense code of 0x4 (hardware error), but about the last 20% of the drive started reporting 0xb (aborted command) in the 1-3 second range. There were still many times it did trigger a reset, how often varied across the drive. Some areas had more resets, others had more returns without the reset. Because this was done through USB, it is difficult to see exactly what is going on.

[maximus]

@zvit, since this is now to an experimental point, can you do a test for me? Originally I saw 60 second times read times when you were using the free version, but I had no idea you were using it through a virtual machine. I would like to you use the method you just did for the recovery (live cd?), but start a new recovery with the default settings and not using the direct mode (leave the mode default). You can use the destination of NULL, as this is not to recover data. I would like a 10-15 minute run, and then post the log.

[maximus]

@zvit, I have another test I would like. I need the full terminal output from a short run of 10-15 minutes with the settings you used for the final recovery. I would also need the log. I need to see what is happening in the terminal to understand what resets are happening in the log. You can use NULL as the destination. If you cannot easily remember the settings, I think you can make a copy of the final log and use that, and do a log reset on it, and I think that will work, but starting with a new log would be better for me.

[zvit]

@maximus I will do the tests soon and update later this morning (it's 5:54 AM here now)

I DO have the settings I used since I was writing them down as I went along (but I don't have the settings of the viewer as I mentioned to pepe )

Note: At first, I had started the reset timings as you recommended, Soft: 6000, Hard: 5800, but somewhere during the recovery I wanted to test lower reset times (hoping it would go faster by spending less time in between resets.) I kept stopping and going lower and lower until the drive wouldn't reset on its own and I had to have to manually unplug and replug the HDD. The "sweet-spot" that I was able to use at the end was Soft: 4000, Hard: 4800. (I didn't change the "Reset Timeout" or "General Timeout".) So that's what I'll use for your tests.

p.s. Since I needed to extract the data to the 1TB spare drive, I moved the 1TB image to my Synology NAS. I hope the live CD can detect a NAS (never noticed.) I actually should have checked this first and initially created the image to the NAS instead of having to move it after. Oh well, next time

[zvit]

UPDATE:

Synology is not showing up in live CD. I will have to research how to do this.
But since the NAS is it's own "computer" so to speak, and I can connect the drive directly to it via it's back USB port, and I can install ubuntu on it, would it be possible to just do the tests directly on the NAS? (If it is, I should have done that before!)

[maximus]

For the tests that I requested, you can use NULL as the destination. I just need the results requested, with no data recovery expected.

[zvit]

UPDATE: I am creating an NFS mount with Synology which should work. Further update to come.

[zvit]

For the tests that I requested, you can use NULL as the destination. I just need the results requested, with no data recovery expected.

Oh, I didn't notice. Ok, I connected the NAS anyway and did it there with NULL.

Attached are the logs and terminals for both tests. Both tests ran for 15 minutes.

p.s.: Correction about the timings I mentioned before:

maximum suggested:
soft reset: 2000 (was too fast and caused me to manually reconnect the HDD cable)
hard reset: 80000
reset timer: 80000
general timer: 240000

My sweet-spot:
soft reset: 4000
hard reset: 4800
reset timer: 10000
general timer: 120000

Attachments

maximus-test-02-final-recovery-settings-terminal.txt

(32.69 KiB) Downloaded 702 times

maximus-test-02-final-recovery-settings-log.txt

(11.77 KiB) Downloaded 795 times

maximus-test-01-default-settings-terminal.txt

(5.67 KiB) Downloaded 838 times

maximus-test-01-default-settings-log.txt

(6.98 KiB) Downloaded 761 times

[maximus]

I can see that when using the OS it hits the internal 60 second timer. Every other time it returns in 60 seconds or what appears to be about 90 seconds. This recovery would have taken much longer without the direct USB mode, probably 8 times longer.

I can also see that when the drive does return with the hardware error, it claims to be returning partial data, which is very interesting.

@zvit, I have one more test with the settings of the final log, but with the cluster size turned down to 8. This will make reading very slow, so I think the best way to do this is to make a copy of the final log to work with, and after you open it, go to the tools menu and choose to reset the log. This will allow not having to read a bunch of good data to get to the results part. You can use NULL as the destination. A 15 minute run should be good.