2 8TB disks corrupted.1 fixed.1 with corrupt partition table

[fzabkar]

It would appear that the boot sector (Indicator B) for the 8TB NTFS volume has been offset by 14 sectors. Originally it was located at LBA 32768, but now it is at LBA 32782. The copy of the boot sector (Indicator C) is still in its original place.

As there is no Indicator for the file system (F), it would appear that the $MFT cannot be found, at least not at its expected location.

Would it be possible to upload the contents of sectors 0 to 32782? DMDE has a Tools -> Copy Sectors function for this purpose.

[Arch Stanton]

Would it be possible to upload the contents of sectors 0 to 32782? DMDE has a Tools -> Copy Sectors function for this purpose.

Agreed. Before restoring I'd like to see what's in 32768.

[Lardman]

Agreed. Before restoring I'd like to see what's in 32768.

My money is on something drivecrypt related, stuff just isn't sitting right.

[pizzatosti]

Agreed. Before restoring I'd like to see what's in 32768.

My money is on something drivecrypt related, stuff just isn't sitting right.

Thing is, that this particular drive was not encrypted in any way, nor had it been before (Deliberately not, so take that out of the equation). It ran fine for days writing and reading. And then suddenly the "corrupt structure" warning on 2 separate folders. While I could still open files from other folders on that disk.. Weird. And after disconnection/reconnection the structure was messed up, just like the other 2 before.
I indeed tried to restore the partition as I proposed on the 29th. But that did not result in a working disk. So I decided it was more practical and quicker to just re-copy the files again.

So: The overall update and end result a few days later:
It seems I have (as good as) all data recovered. GetDataBack recovered the 5,7TB. DMDE found an additional ~1TB of RAW data. And it was able to filter out/exlude all results from the MFT results. And from those raw results, based on quick tests, I'll be able to filter out what was on a backup, meaning I'll end up with a small(er) selection of files that still require manual actions. But that's ok given the situation. I'll pick that up later.
And the SRC and BU disks are in sync again. So all is good.

I am following up with AMD/Asus on the USB glitches topic and submitted a support ticket. After some more reading I found too many commonalities to look into it. Like the disconnects getting worse with intenser cpu loads (for instance the webcam/mic disconnects during Teams, which is a known resource hog). I've had the same happen often. Can be a coincidence, but still worth checking out if that results in a more stable platform.
Let's see what that takes me.

Thanks again all for your input, time and assistance!

[fzabkar]

If you can provide a dump of the requested sectors, someone may be able to determine the mechanism behind the corruption. I would be very surprised if AMD would be inclined to pursue your case, especially when the fault could be due to the USB-SATA bridge rather than their USB host.

In fact @Arch Stanton has investigated similar cases of USB corruption involving offsets in the file system.

[Arch Stanton]

In fact @Arch Stanton has investigated similar cases of USB corruption involving offsets in the file system.

Speaking of which: Did you look at the PDF I linked to in Scott's group? And if so, any ideas, insights, thoughts? If so I'd love to hear them.

[fzabkar]

Speaking of which: Did you look at the PDF I linked to in Scott's group?

I made some observations in Scott's group. Basically I understand the non-deterministic sectors, but I don't understand why these would result in an offset.

[Arch Stanton]

Yeah, I initially assumed offset would continue on and on. However I still feel the offset is obvious in this example. NTFS BS itself tells us it's at LBA 63. It shifted by one sector.

Attachments

[fzabkar]

Yeah, I initially assumed offset would continue on and on. However I still feel the offset is obvious in this example. NTFS BS itself tells us it's at LBA 63. It shifted by one sector.

I agree that an offset exists, I just don't understand the mechanism behind it. My understanding from the PDF is that a sector is replaced rather than inserted, but that is clearly not the case in your example.

[Arch Stanton]

Yeah, I initially assumed offset would continue on and on. However I still feel the offset is obvious in this example. NTFS BS itself tells us it's at LBA 63. It shifted by one sector.

I agree that an offset exists, I just don't understand the mechanism behind it. My understanding from the PDF is that a sector is replaced rather than inserted, but that is clearly not the case in your example.

Yeah, nor in my new case in which case ROOT folder shifts.

Also note that the offset idea isn't mine, others mention it too. Example (translated) "Conclusion: The appearance of USBC sectors can indicate problems with the device, as well as cause biases in the data area. When recovering, it is recommended to conduct additional analysis and take into account the displacements (shifts) that they cause." - https://512byte.ua/articles/usbc-na-fleshke.html