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

[Lardman]

Without wanting to give duplicate or conflicting advice as Arch Stanton is far better at this than I am.

After 5minutes it was still at 0% of the disk but that scan allready listed over 250files matching the type of extensions.

You have raw files this is good - Id expect them to be valid, but yes spot check a few. Use whatever tool works - you're getting results with DMDE so stick with it. If it were me, I would finish a raw scan and recover the data files missing from your last backup, they should be selectable by date. Once you've done that and data is no longer critical, I'd move on to consider what's wrong with the FS.

[pizzatosti]

ok. This is getting promising:
I opened the volume. Had a scan run for a few minutes.
It found some jpegs, docx and .mpg. I previewed several and saved a few from different filetypes to disk (to a location outside this disk of course). The files are randomly numbered/named, but the contents appears to be correct. I could open the docx, the .jpg and .mpg properly.

File contents wise this looks promising based on a short scan. However, any thoughts on how the filename corruption can be restored?

[Arch Stanton]

as Arch Stanton is far better at this than I am.

Huh? Why? I am just reasoning my way through this actually. My idea is, logical volume then I assume Drive Cryptor is active as it works at volume level as far as I can tell. If we scan outside that we're only seeing encrypted data.

Thus far DMDE did not detect MFT. Either boot sector is off and does not point to correct location, or it does and MFT itself is hosed, at least start of it.

You are right, we'd need full scan to see if it can be found. Once you find that indeed we have filenames and dates etc.. It may be other tools are quicker or better. ZAR perhaps or GetDataBack. For some reason I am always under the impression these make most effort to reassemble NTFS file systems with only partial MFT. It's just that DMDE price is so hard to beat....

[Lardman]

File contents wise this looks promising based on a short scan. However, any thoughts on how the filename corruption can be restored?

This information is not contained within the files themselves but is part of the filesystem. Allow the scan to finish, then post the results - don't forget to save the scan results so you don't have to keep repeating it.

as Arch Stanton is far better at this than I am.

Huh? Why?

..... because I've been following your work and learning from it for a number of year much like I have fzabkar

[pizzatosti]

Thus far DMDE did not detect MFT. Either boot sector is off and does not point to correct location, or it does and MFT itself is hosed, at least start of it.
You are right, we'd need full scan to see if it can be found. Once you find that indeed we have filenames and dates etc.. It may be other tools are quicker or better. ZAR perhaps or GetDataBack. For some reason I am always under the impression these make most effort to reassemble NTFS file systems with only partial MFT. It's just that DMDE price is so hard to beat....

I had another look at GetDataBack after the above. I could previously not see the logical disk so I skipped it, but it turns out the settings has the option "Show logical disk" and I could now scan the logical disk.
I had GetDataBack do a first scan and it found a lot of files including proper filenames. Level 2 scan presented some 1.8TB of data with proper filenames. So I got a license, recovered some files which worked. I also had a few files that were not properly copied.

I now have the level 4 scan running. Will take about a day. At 2% now. Found some 7300 files, 24687 MFT entries ($MFT) and 1 index allocs(allocated?). Will see in a day how this will turns out and how much of this is actually recoverable.
Assuming a partial recovery, I can always see if I can find additional files via a raw recovery... I'll first see what the results are after this scan....

[pizzatosti]

GDB is at 90%. Found way more files then expected. Perhaps more file changes due to syncing over time if I'd guess.
MFT entries were listed at 24687 right at the beginning. I tried to do some more homework on the topic between tasks. But is the number of MFT entries the number of files that were on the disk prio to corruption? Is that correct?
I did some Googling on the "Index Allocs" number, but so far I couldn't find wether for instance a higher number indicates more chances of recovery for instance.

Any thoughts on what I should expect or be aware of after the completion of this scan this evening?

Attachments

[Arch Stanton]

But is the number of MFT entries the number of files that were on the disk prio to corruption? Is that correct?

Approximately, yes. Theoretically one file can occupy multiple entries, can point to an index but that's the general amount of files. Is that what you expect or did you expect more?

File starts can also be false positives. So in screenshot it seems it's detecting BMP and PDF files but at this point you can't tell if they're actual files.

[Arch Stanton]

File contents wise this looks promising based on a short scan. However, any thoughts on how the filename corruption can be restored?

This information is not contained within the files themselves but is part of the filesystem. Allow the scan to finish, then post the results - don't forget to save the scan results so you don't have to keep repeating it.

as Arch Stanton is far better at this than I am.

Huh? Why?

..... because I've been following your work and learning from it for a number of year much like I have fzabkar

Well TBH it is you who first suggests scanning the logical drive and it's me who is observing your answers in topics on trouble shooting PCBs etc.. That's stuff I want to learn about. To a degree it pays off as the other week I was able to repair a USB flash drive using my eyes, a multimeter and a soldering iron

[fzabkar]

It's too late now, but in GDB is it possible to restrict the search to NTFS elements?

[Arch Stanton]

It's too late now, but in GDB is it possible to restrict the search to NTFS elements?

I think select level ** or *** may accomplish that. I am not sure. I'll experiment. It may be though that these are used for parameter detection.

[pizzatosti]

It's too late now, but in GDB is it possible to restrict the search to NTFS elements?

I'd have to check when I can access those screens again, but I believe I only had NTFS selected in Level*/**, but enabled it prio to starting the L*** scan. Expected it to not hurt the findings, just slow the scanning down.

Scan has completed btw. Next it moved on to creating a recovery tree.

On the questions of the nr of files:
Based on the backup I'd expect around 16000 files at least. Thing is that I can't say for sure if I did or didn't copy a dev backup folder which could be a few thousand files. So ~24k files could be correct.

Attachments

GDB_Progress_100procent_recov tree_creating.png (18.1 KiB) Viewed 11458 times

[pizzatosti]

(re)creation of the recovery tree was completed in 1,5hrs. Folder names are gone, but all filenames are in order.

GetDataBack presented about 5,76 TB of data. I recall the disk not having a lot of free space so there is certainly a chunk of data not accounted for.
That makes sense as based on the visual comparison with the last backup I know that certain folders have more files then is now listed for recovery.

I've batch selected files from several folders and I've succesfully copied about 150GB without any copy corruption errors and I could open/view/access all files so far.

Even knowing this list is not complete, for now I'm allready very happy with this result of course. My idea now is to first copy all the recoverable data and once that is done, determine what I'm missing and perhaps see if by scraping raw data, I can later identity the missing files.

Thanks for all input and tips so far to get to this point!!! I'll update this post when relevant findings arise.

[pizzatosti]

OK. One happy camper here. I've copied/recovered almost 5TB. Not a single copy error and I have yet to spot a file that could not be opened/started.
So at this point I'm confident that the remaining 700GB that is listed for recovery will also be succesfull. Fingers crossed.

After comparing the recovered and remaining data with my backup:

-It seems most more recent data is present. Which is good and will result in minimal lost data (yet to exactly determine that later)

-As mentioned it is clear that data is missing. I'm trying to determine why (with the goal to point to a cause, leading to a solution)
1 folder with 52 files is not listed for recovery, and 86 files from a second folder are missing (276 where that should be 362)
I'm confident that these should be on this disk.

I've concluded that these 138 files have in common is that they are among the oldest files in the disk (read: among the first files initially added to this disk)

To be honest: These files are less critital for recovery, but at this point I'm now very interested in this topic. So I'm eager to also find out what is going on and further learn how to best act in future situations:

My assumption and subsequent question:
Given the lack of errors in data integrity, I'm now assuming that the data of these missing (138) files is still there, but that the MFT entries of these files is gone. That this would indicate that part of the "oldest" part of the MFT would be damaged.

Does that make sense? And is it correct that scraping the disk for raw files could still find those files (most likely without it's filename)? Based on filesizes I expect to be able to filter out duplicates.

Or perhaps any other suggestions?

[Lardman]

So I'm eager to also find out what is going on and further learn how to best act in future situations:

There shouldn't be any future situations - you've now aware how valuable backing up is. Whilst is sounds like you had a backup strategy is appears it needed to be a bit more robust to provide the cover you needed. You should concentrate there first, hard drives are cheap, DR isn't and should always be the last resort.

Given the lack of errors in data integrity, I'm now assuming that the data of these missing (138) files is still there, but that the MFT entries of these files is gone. That this would indicate that part of the "oldest" part of the MFT would be damaged.

That appears to be a reasonable assumption, it's been a long time since I used GDB (it didn't have a tiled interface back then !) but I assume given the time taken phase 4 is a raw carve.

Now you have the data safe - you could find the MFT and see if it repairable either automatically or by hand. Other than time there's no reason not to point other data recovery tools at the drive to see if they do better the GDB. It's a very deep rabbit hole - but feel free to dive down it

[Arch Stanton]

Given the lack of errors in data integrity, I'm now assuming that the data of these missing (138) files is still there

What did you try to see if these files are there? Some times file can be found but the folder they were 'linked to' can not. So I am suggesting these files perhaps were actually recovered but linked to nothing or folder the recovery software simply made up. Files can be linked to folder using data in MFT, they point to a 'parent'. If entry for parent does not exist or is used for something else it may not be possible to integrate these files into folder structure. In software I made years ago I simply made folder 'Unknown1234 in root, your software may be doing something similar.

And is it correct that scraping the disk for raw files could still find those files (most likely without it's filename)? Based on filesizes I expect to be able to filter out duplicates.

But you won't necessarily get accurate file sizes. What type of files are you looking for? It depends somewhat on file type if an accurate size can be guestimated.

[fzabkar]

It might be interesting to see what this tool finds:

https://dmitrybrant.com/ntfswalker

[pizzatosti]

Trying to prevent TL;DR.....

Good new and bad news...

Good news: The full scan by DMDE revelad 25175 files including filenames. First check shows that the (at least some) files that GetDataBack was not seeing, I can recover now, although with their original. Good enough. Think that covers my recovery needs.

More good news: I think I've determined the root cause... leading to the bad news:

The destination disk that I recovered all files to also got corrupted!!

With more Googling on various terms: I came across similar issues that a user reported. This was caused by (known) USB issues with certain AMD chipsets giving short usb disconnections. I have the exact same cpu/mobo. AMD 5800x with an Asus ROG Strix X570-E gaming.
When I built my new PC this spring, out of habit I had applied the latest patch at that moment. That patch from april(?) supposedly included a patch for the usb issues. But at the time I did not really pay attention/dove into this issue.

My previous PC was Intel based.
Also, with the usb3 bay I never had a problem with my Intel PC and that bay is in in regular use being connected to another pc. So I dare to say the usb3 bay is not the issue.

But today also my recovery destination disk all of a sudden presented the corruption error when accessing one specific folder, but I could still open files from other folders on that disk(?!). This happened after a few hours of idle time (ports are configured to not go in sleep btw)

I think (the assumption I'm going by now based on what I read) is that possibly (short) usb disconnections while an external disk is connected, can screw up the disk MFT/GPT as this can happen during copy/file manipulation actions. Sounds plausible, right?

To be safe, I did not encrypt the recovery destination disk. This disk was initialized in Win Disk manager as GPT and formatted. Again 1 single partition spanning the 8TB disk.

I tried to eject the disk, but Windows refused.
I shutdown the PC. Later (after reading the above on AMD/USB) I connected the bay with disk to my other machine. And, as unfortunately expected, I was asked to format the disk (which I did not do of course)

Next, I opened the disk with DMDE. Perhaps to due being initialized/formatted in Windows, DMDE actually seems to find and present partitions for recovery. I've included screens from DMDE for this disk. Should I indeed choose to restore Volume2? And should I do that from the Physical disk view, or from the Logical disk view? Any advice/experience?

So to be clear: I'm talking about the disk that I used to recover to. Disk1 that started this topic, and Clone1 of disk Disk1 are still untouched. So I could repeat the GDB procedure that was succesfull. But if I can restore the recovery disk that would spare me another 2 days of scanning and copying again. I had saved the recovery log btw in GDB.

I'll be applying more recent bios updates asap that came available in the last few months. And NO, I won't connect an external harddisk again via usb on my AMD machine untill this is sorted. I read lot's of users still having these issues even after the most recent bios updates. Perhaps I'll have a look at a PCI USB card just to skip the onboard for external disks. But that's for later...

Attachments

0Format.PNG (7.55 KiB) Viewed 11152 times

[Lardman]

Your post illustrated a very valuable point. USB has no place in DR, I think we all made the assumption you were working sata only. Needless to say to that from now on, leave the usb dock alone. I'm not convinced that disconnects are the entire cause but certainly wouldn't help.

Without the encryption you should be able to work with the physical disk directly, do you have a right click option to undelete volume 1, start there. You did save the scan results from GDB onto another disk didn't you? If so, worst case you just extract the files again - lost time but only half of it.

.... where's your backup to restore then !

[pizzatosti]

Your post illustrated a very valuable point. USB has no place in DR

Well, basically I'd agree. In this case it actually was a consious choice as I quickly noticed it was hard to tell the disk apart, and I wanted to avoid a mix up between the source/clone (on sata) and the disk on usb where the to-be-recoved files would go.

I'm not convinced that disconnects are the entire cause but certainly wouldn't help.

I agree. While in this case the given errors basically match situations of uncontrolled disconnects (during writing the disk) combined with to "what has changed from a years of working situation" combined with "known issues that were introduced after the working situation". Still.. not 100% indeed.

Without the encryption you should be able to work with the physical disk directly, do you have a right click option to undelete volume 1, start there. You did save the scan results from GDB onto another disk didn't you? If so, worst case you just extract the files again - lost time but only half of it.

All recovery saves (files/logs) where of course saved to other disks;-)

So just to be sure: Physical Disk -> select Volume01 -> Restore -> then Yes in the attached dialog. Correct?

where's your backup to restore then !

That's why I used 2 disks apart from the source. So I can play and not panic when that goes wrong.. (but still annoyed haha)

Attachments

[Lardman]

So just to be sure: Physical Disk -> select Volume01 -> Restore -> then Yes in the attached dialog. Correct?

To be honest I'm almost tempted to tell you to run chkdsk .... it's only the recovery destination anyway. If it dumps a few files off the mft but gets the rest up and running it might be the easiest (quickest) option. Not sure - depends on the damage I suppose.