Help me assembly JBOD/spanned in DMDE with missing drive

[Avenge7058]

Doing what exactly?

After "Click 'all found / virtual file system' > pure FS".
It is shown in "Screenshot (188)"

Oh and, what happend to 3rd disk anyway? It failed you said, but how exactly, is it dead?

Yes, it's dead
the heads are broken

[Arch Stanton]

Also, when I look at MFT between LUN#0 and #1, on LUN#0 it shows file names etc.
However, on the LUN#1, it's not

Screenshot (191).png

How did you get there, just scroll MFT?

[Avenge7058]

How did you get there, just scroll MFT?

Yes

[Arch Stanton]

Towel > ring ..

I think it should work unless I overlook something. Or make logical error somewhere.

If these were my disks I'd now probably ..

Scan 2nd drive. I'd first try select the 4 TB or so partition, meta data folder > $Boot > DBL click .. Then tools > search for special > MFT record > see I can find MFT entry with record number 204928 (that would be continuation of MFT).

Alternative do full scan of drive 2. Once finished click all found / virtual FS > advanced TAB > Volume FS fragments > see if MFT chunk is found that starts with record 204928 (#File column).

Maybe I'd just run full scan on Archive on reassembled JBOD (reassemble as done before), then look at click all found / virtual FS > advanced TAB > Volume FS fragments > see if MFT chunk is found that starts with 204928 (#File column). Then compare LBA address for that with 14411094669 to see how far we're off, see if it's something I could make sense of.

Thing is MFT runs expect continuation of MFT at LBA 14411094669 (of volume). Two things can be wrong: we assembled array correctly and it's simply not there or it's there but we assembled array incorrectly. If it's there a full scan should find it whether we have array wrong or not. And so I'd check that in advanced TAB of FS reconstruction as explained above.

[Avenge7058]

Towel > ring ..

Where do I find it?

Maybe I'd just run full scan on Archive on reassembled JBOD

I've performed a full (NTFS + RAW) scan and have it saved, but I did it without offsets.

[Arch Stanton]

Just occurred to me we see MFT break at record 204928 but pure FS reconstruction complains about record 230945 which suggests it may be physically unable to read location where it expects 230945. Did you add that null disk again? If not it suggests part of MFT was on drive 3.

[Arch Stanton]

Towel > ring ..

Where do I find it?

Maybe I'd just run full scan on Archive on reassembled JBOD

I've performed a full (NTFS + RAW) scan and have it saved, but I did it without offsets.

You can still see if it found record 204928 as start for one of the MFT chunks.

Towel > ring was meant as "I throw the towel in the ring".

[Avenge7058]

I can see something like this:

[Avenge7058]

see if MFT chunk is found that starts with 204928

Yes I found it
it's the second one on a first screenshot

pure FS reconstruction complains about record 230945

It was just one of many

[Arch Stanton]

It found it @ LBA 14411163992 while 'we' expect it @ LBA 14411094669 + we need to consider you reassembled with offset 0 rather than 32768. So it basically found it at 14411163992 - 32768, right? So 14411131224.

So we're 14411094669 - 14411131224 = -36555 sectors off, right? .. I don't get it, you?

@fzabkar, you see it?

[Arch Stanton]

Anyway, we see our 2 MFT chunks, but apart from those no significant MFT chunks at all. All MFT entries added up account for 300000+ files. How many files do you expect there to be?

[Arch Stanton]

You could try make first member 36555 sectors smaller., we're just 8 clusters off, somewhere. Use my offsets, not zero.

[Avenge7058]

I don't know, but i have 3 backup's of my old laptop drive an my pc drive with windows folder etc so it can be 300 000+ files
(of course in addition to my medias that I want to get out)

[Arch Stanton]

You can always try carve the 2nd drive but you'll lose filenames.

[Avenge7058]

You could try make first member 36555 sectors smaller., we're just 8 clusters off, somewhere. Use my offsets, not zero.

It made it better!

now it complained only once while building virtual FS, and we have some entries on LUN#1

[Arch Stanton]

But you need to check some files. Okay it and then preferably check JPEGs that were written recently. See if you can preview them.

[Avenge7058]

No, the files are broken which is logical since I think that if we still don't have a full MFT it means that we have offset somewhere so files will be read incorrectly?

And I don't know if it's helpful, but when I scroll down on this MFT file further it changes to something like that:

[Arch Stanton]

No, the files are broken which is logical since I think that if we still don't have a full MFT it means that we have offset somewhere so files will be read incorrectly?

And I don't know if it's helpful, but when I scroll down on this MFT file further it changes to something like that:

Screenshot (199).png

Whether we have full MFT or not does not matter for files we have. If you have MFT entry for a file you have everything, but offsets become important then. MFT references clusters, cluster addresses and an address makes sense only against correct offset.

[Avenge7058]

What I can add more is that these files from LUN#1 are in this wiried folders outside off myoryginal FS structure

[Arch Stanton]

At this point I'd try a full scan with offsets I gave.