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



Yes, it's dead
the heads are broken

How did you get there, just scroll MFT?

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Yes

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.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Where do I find it?



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

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.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

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".

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

I can see something like this:

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


It was just one of many

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?

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

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?

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

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

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

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)

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

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

It made it better!

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

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

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

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:

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.

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

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

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

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service