Question Windows 10 Spanned Volume Suddenly Missing (Dynamic Disks: "Invalid")

oblivioncth · Aug 14, 2019

Hi,

Normally I'd try quite a bit myself before posting here but I'm afraid to try much since data is on the line. As far as I can tell this seems to be a software issue rather than a hardware problem, though I can't be 100% sure. I say this because both drives involved are fairly new, still show up within the BIOS and device manager OK, and have no SMART errors reported, so its more likely the issue is more along the lines of partition corruption.

Also, I'd like to get this out of the way: I know I should have this data backed up, but unfortunately its a large amount that isn't cheap to backup and so I was waiting a few months until I could afford another set a drives to occasionally mirror these to. Annoyingly, barely anytime passed before this happened so it goes without saying that I did't get to the point where I could back these drives up yet.

I wish I could say exactly what happened, but unfortunately there is a small blank spot. Anyway, here is what I know happened:

Originally had an 8TB drive (ST8000DM004) that I was storing quite a bit on that I bought a few months back (within this year)
I needed more space for the same kind of data so I bought another ST8000DM004, popped it into the same SATA controller as the other 8TB drive, converted the existing disk and it into dynamic disks, and then extended the original volume into an extended/spanned volume across both drives for a total of 14.6TB of usable space.
Moved some data around and set up a large task of extraction and compression on this expanded partition
Left home for a few days while this was processing. Couldn't remote into my machine because of an annoying weird issue with RDC that I've had happen before if my machine has gone a very long time without reboots. So, I asked someone else at home to go to the PC, ensure it had finished its operations, and then let me know that was the case so I could give the OK to restart the machine.
This is where the "blank" occurs. They misunderstood what I said and thought I wanted them to restart assuming the process was done WITHOUT confirmation to me. According to them everything up on the machine was just completion windows that they clicked through hitting "OK" on each and then restarted the machine. So in theory the drives were not in use and the machine was doing nothing when it was restarted, but I have no way of knowing for sure and really wish I knew exactly what was up on screen from the last time I had looked :/
I remote into my machine no problem now that it has been restarted and immediately notice that the 14+ TB spanned volume isn't showing up.
Check device manager and both drives are there, check CrystalDiskInfo and see no S.M.A.R.T oddities
Opening Windows Disk Management shows both disks with no volumes/partitions and on left shows them with the little red and white down arrow and they each say "Dynamic" and "Invalid"
Opening AOMEI partition assistance shows the disks marked as dynamic and both drives as "Unallocated"
Opening Acronis Disk Director shows the following errors, the last of which I believe refers to the drives themselves:

I am hopping there is a way to repair the partition info that details how the volume is spanned across the drives, or at very least recover the info a bit at a time and off load it elsewhere (though to be honest I'm not sure where I can fit this much). I'm not quite sure but I believe this was the first time the PC was restarted since the second drive was install and the volume was spanned, so it could be there was an issue with how the drive info was initially written to the LDM database and now that the system has been rebooted Windows cannot enumerate the disks correctly due to a corrupted LDM.

Thanks for any suggestions. Desperate here

EDIT (More Info):
I'm mostly certain at this point this is some dumb (but challenging) issue with the volume/parition information being corrupted alone as I am able to open both disks in HxD and all of the data seems to be there and is not garbage data. Obviously I can't confirm 100% integrity of 12TBish of data but searching for various string values I know are in certain files on those drives does returns results and there are no errors when trying to access the drive.

fzabkar · Aug 14, 2019

Could you show us how the Partitions appear in DMDE?

https://dmde.com/

oblivioncth · Aug 14, 2019

fzabkar said:
Could you show us how the Partitions appear in DMDE?

https://dmde.com/

Hey thanks for the help.

Sure can, though I don't know exactly want you want so I hope this suffices.

Drive 3 (1st half of the span and the drive I had first) overview:

Drive 4 (2nd half of the span and the drive I had second) overview:

I'm not so sure about the data integrity of the second drive anymore based on what I'm seeing in HxD, though I really have no idea how Windows handles spanned disks at the byte level and can't be exactly sure at which point the first disk filled up and exactly which files ended up on the second disk.

Just let me know if you need more specific info from DMDE.

fzabkar · Aug 14, 2019

ISTM that both drives have been "initialised" (black partitions) but thankfully not reformatted. However, I'm confused in regards to the greyed out partitions.

ICBW, but ISTM that drive 4 is the first drive in the span, while drive 3 is second. "Archive" appears to be the 16TB spanned volume. It contains the boot sector (B) at the beginning of the volume.

$Volume 3 or $Volume 2 appears to be the second half of the spanned volume. These contain a copy of the boot sector (C) at the end of the volume.

If you double-click the Archive volume and expand the Root, do you see your original File/Folder tree?

oblivioncth · Aug 14, 2019

fzabkar said:
ISTM that both drives have been "initialised" (black partitions) but thankfully not reformatted. However, I'm confused in regards to the greyed out partitions.

ICBW, but ISTM that drive 4 is the first drive in the span, while drive 3 is second. "Archive" appears to be the 16TB spanned volume. It contains the boot sector (B) at the beginning of the volume.

$Volume 3 or $Volume 2 appears to be the second half of the spanned volume. These contain a copy of the boot sector (C) at the end of the volume.

If you double-click the Archive volume and expand the Root, do you see your original File/Folder tree?

You are correct, I had made assumptions about the drive order based on which SATA ports I had plugged them into but I must have gotten them backwards, as based on the power on hour count the 4th drive is definitely the 1st part and the 3rd drive is the 2nd part.

When I tick "found" and double click on "Archive" (which yes, was the volume name) I get "Volume does not fit into device", which I'm guessing is since it was a spanned volume. So I selected "Use this virtual volume size" just to try and view the files. Under the virtual "$Root" I do have the original structure and everything seems to be there, other than some files I had been working with just before the volume went down. Some folders have nothing, some folders have some of the files. Most likely the missing files are over on the other drive.

For Drive 3, it finds 4 Volumes like you noted, though its a bit confusing that multiple of them are marked as the full volume size (14.6TB), but I'm guessing this is due to how spanned volume meta data is handled. Volume 4 on this disk also gives "Volume does not fit into device", while all 4 volumes give "There are no any valid MFT Start Cluster", again probably since this is the 2nd half of the span.

Trying to find any files on all 4 volumes (largely discounting Volume 4 since it seems to be a boot sector as you noted) using "Continue with these parameters" yielded no file structure (completely empty under $Root) for any of them. The "Scan for FS parameters" option seems like it will take quite a while, which is to be expected given the size of the drive. It did not exceed 0% even after near 10 minutes of running. I don't know if there is a way to tell this software to that these two drives are supposed to have a spanned volume and have it try to mount the contiguous file system in the same way it does when I try to browse "Archive" on just the one.

Overall I can't seem to find any files on the 3rd drive from intuition alone (other than if the scan will do it, though that will take quite a long time to complete per volume). I haven't used this software at all before but I wish I had known about it and is seems incredibly powerful. I do know the data is there though as I was able to locate the raw data of some text files via HxD on Drive 3 in particular like I had mentioned before. I'm guessing it can't enumerate the file system as easily on Drive 3 since Drive 4 definitely is the start of the full volume. I'm willing to wait for the FS scan if required, though see what I'm shooting for below:

So, at the very least I can get the files back from the first drive (which is about 90% of them), though I currently don't have any free storage capable of holding that, so if it is somehow possible to stitch back together the spanned volume that would be highly ideal. Otherwise I will need to come up with some way to temporarily store 12ish TB of data.

fzabkar · Aug 14, 2019

I think that if we are patient and methodical, we might be able to reconstruct the spanned volume by editing the LDM metadata. In fact we may only need to delete the entries for the new initialised partitions and re-enable the old LDM metadata.

The Archive partition begins at sector 264192. If we assume that the original LDM metadata partition begins at sector 260130, then we would need to examine this area (ie sectors 260130 to 264191) with a hex editor, or we could use DMDE itself. If you could use DMDE to Copy Sectors to a file, and then upload this dump, I would be interested in examining it with you.

oblivioncth · Aug 15, 2019

fzabkar said:
I think that if we are patient and methodical, we might be able to reconstruct the spanned volume by editing the LDM metadata. In fact we may only need to delete the entries for the new initialised partitions and re-enable the old LDM metadata.

The Archive partition begins at sector 264192. If we assume that the original LDM metadata partition begins at sector 260130, then we would need to examine this area (ie sectors 260130 to 264191) with a hex editor, or we could use DMDE itself. If you could use DMDE to Copy Sectors to a file, and then upload this dump, I would be interested in examining it with you.

Excellent, I can't ask for more. Reading back my posts I realized I stated my desire to repair to archive instead of simply recovering files many times. I didn't mean to seem so desperate in that particular regard, I was just a bit distressed by the fact I could only find mentions about file recovery for spanned volumes and nothing about actually attempting to restore the volume.

I do understand there are no guarantees with this, but the fact that all the data seems to be present does start us out with things looking good. So, we will start were you suggested.

Here is an overview of the partitions that DMDE picked up so you have an idea of what you'll be looking at (good call on the sector range):

Here are sectors 260130:264191 of Drive 4:
https://mega.nz/#!fENmwQRL!4UpaW-UWr3UN1_dBY18MLVXQ2E1DaIWP8sbtR08XiLM

There is not much there, but I have little knowledge of the format of the NTFS file system so perhaps its alright.

Just out of curiosity I peaked at what was in sectors 0 through 260129 and it was entirely blank except for sparse data that all seemed to be related to the Microsoft System Reserved partition (as expected).

I also let a full scan of Drive 3 run overnight and saved it once it reached 100% in case it is of use to us later. It didn't seem to locate a full file-system (again, not surprised since its the second half of a spanned volume), but that doesn't mean the log is outright useless).

fzabkar · Aug 15, 2019

I found this resource:

https://flatcap.org/linux-ntfs/ldm/index.html

I would also locate the boot sector and its copy. These are the first and last sectors of the Archive volume. They contain information which will help us to determine the range of sectors corresponding to each half of the spanned volume.

This is another good resource:

https://thestarman.pcministry.com/asm/mbr/index.html

I've started skimming through your LDM Metadata dump and found encouraging references to Disk 1 and 2. It might be worthwhile dumping the same sector range from Disk 2. I would examine the dump before posting it, just in case it contains personal data rather than metadata.

DMDE can reconstruct a logical volume from two or more spanned drives. It remains to be seen whether the "initialisation" process has overwritten any data (probably, at least on drive 2), but we should at least be able to see the full 16TB volume after determining various sector offsets from the information in the boot sectors.

To construct a spanned volume, we go to ...

Drive -> Construct RAID
select JBOD/Spanned from dropdown list
Menu -> Add Disk -> OK
r-click disk and select Partition / Offset / Segment
select appropriate values for First, Last and Number of Sectors

BTW, I have tested this feature by "logically" splitting my single drive into two parts and then stitching them back together by specifying the appropriate sizes and offsets. It works great!

BTW2, when searching for NTFS boot sectors, you can start at the end of the drive and search in reverse. That should find the copy/copies in the quickest time.

oblivioncth · Aug 16, 2019

Scan is going. Will report back ASAP.

oblivioncth · Aug 16, 2019

fzabkar said:
I found this resource:

https://flatcap.org/linux-ntfs/ldm/index.html

I would also locate the boot sector and its copy. These are the first and last sectors of the Archive volume. They contain information which will help us to determine the range of sectors corresponding to each half of the spanned volume.

This is another good resource:

https://thestarman.pcministry.com/asm/mbr/index.html

I've started skimming through your LDM Metadata dump and found encouraging references to Disk 1 and 2. It might be worthwhile dumping the same sector range from Disk 2. I would examine the dump before posting it, just in case it contains personal data rather than metadata.

DMDE can reconstruct a logical volume from two or more spanned drives. It remains to be seen whether the "initialisation" process has overwritten any data (probably, at least on drive 2), but we should at least be able to see the full 16TB volume after determining various sector offsets from the information in the boot sectors.

To construct a spanned volume, we go to ...

Drive -> Construct RAID
select JBOD/Spanned from dropdown list
Menu -> Add Disk -> OK
r-click disk and select Partition / Offset / Segment
select appropriate values for First, Last and Number of Sectors
BTW, I have tested this feature by "logically" splitting my single drive into two parts and then stitching them back together by specifying the appropriate sizes and offsets. It works great!

BTW2, when searching for NTFS boot sectors, you can start at the end of the drive and search in reverse. That should find the copy/copies in the quickest time.

Alright, good resources for sure. Glad to here there is a way to restore the volume if we can get the meta data correct, thanks a bunch for testing that out.

I grabbed everything you mentioned and organized it and everything else in a folder on MEGA for easy access. I made sure nothing contained any unique/personal data that matters.

https://mega.nz/#F!nIsF3CzQ!-ir_zavsX1Pg-i913TbNKQ

Other than some extras, the main new data I uploaded are:

1) A manual dump of the first 2 sectors of "Archive" on Drive 4. I wanted to do a manual dump of the last two of 'Archive' on Drive 3 but it wasn't quite clear where the end "should" be. On Drive 4 it shows the last sector of 'Archive' reported as "31, 255, 840, 760" while on Drive 4, which corresponds to sector "15, 627, 787, 593" (simple subtraction) on Drive 3, but while viewing Drive 3 it shows the LDM data partition ending at sector "15, 628, 053, 134". If you account for the metadata partition on Drive 3 the equivalent still only adds up to "15, 628, 049, 770". Its close, but none of them line up. Let me know if you want to see any sectors around this mark. The manual dump of the first sector of 'Archive' did line up with where DMDE found the bootsector on its own.

2) The exact sectors found when searching for NTFS bootsectors in DMDE while going forward on Drive 4 and backwards on Drive 3. It's a little concerning how far in from the end that the bootsector copy was on Deive 2 (about 1/3 of the total drive space in) as I'm sure I expanded the volume across the entire drive. it may have to do with how the disk was reinitialized (however the hell that happened), but the "End Bootsector" is the first one it found while searching backwards from the end. I have the scan going still in case it finds another on Drive 3 for some odd reason.

3) The same span of data you initially requested, but on Drive 3 like you mentioned. This did seem to contain some actual data, but nothing that is at all recognizable as anything in particular

The scan log for drive 3 has "volstarts" that may be useful in determining the correct offsets for restoring the original volume like you explained.

EDIT:
I realized I screwed up and that second bootsector dump (the 'Archive End' one that was marked from Drive 3) had actually been found while scanning backwards on Drive 4 (curious as to why it was there then). I renamed it correctly in the MEGA folder and am now about to scan Drive 3.

EDIT 2:
Ok well that was fast. The bootsector copy at the end of 'Archive' present on Drive 3 turned out to be the very last sector and so it was found instantly. I uploaded it to the folder and renamed the files to hopefully be more clear as to what they contain.

fzabkar · Aug 16, 2019

Neither of your boot sectors on drive #3 match the boot sector on drive #4. In fact there appear to be 3 copies of the boot sector at the end of drive #3. ISTM that DMDE is confusing us by identifying each boot sector as a copy, and each copy as a boot sector.

For example, the indicators for $Volume 04 are "Bxxx" which implies that DMDE has found a boot sector with no corresponding file system. However, I believe that this is actually the copy of the boot sector at LBA 264192 on drive #4, ie the "Archive" volume.

The other volumes on drive #3 indicate "xCxx", which would normally point to copies of boot sectors. However, I believe that these are actual boot sectors, not copies. Moreover, because DMDE thinks these are copies, it believes that the boot sector must be located at a negative offset.

I would dump the first sector of $Volume 04 (15 628 050 ...), plus the following sectors:

$Volume 03

15628050458
15628050459

$Volume 02

15628050465
15628050466

I suspect that $Volume 02 is the one that we are after.

oblivioncth · Aug 16, 2019

fzabkar said:
Neither of your boot sectors on drive #3 match the boot sector on drive #4. In fact there appear to be 3 copies of the boot sector at the end of drive #3. ISTM that DMDE is confusing us by identifying each boot sector as a copy, and each copy as a boot sector.

For example, the indicators for $Volume 04 are "Bxxx" which implies that DMDE has found a boot sector with no corresponding file system. However, I believe that this is actually the copy of the boot sector at LBA 264192 on drive #4, ie the "Archive" volume.

The other volumes on drive #3 indicate "xCxx", which would normally point to copies of boot sectors. However, I believe that these are actual boot sectors, not copies. Moreover, because DMDE thinks these are copies, it believes that the boot sector must be located at a negative offset.

I would dump the first sector of $Volume 04 (15 628 050 ...), plus the following sectors:

$Volume 03

15628050458
15628050459

$Volume 02

15628050465
15628050466

I suspect that $Volume 02 is the one that we are after.

I just want to clarify that the first bootsector I thought I found on Drive 3 at the end was actually on Drive 4 so the only boot sector I found on Drive 3 in the end is the one file named "Drive 3 - 'Archive' End Bootsector (Copy) EXACT (found with DMDE)[dev3_lba15628052479_1]" in the MEGA folder. I mention this since you mention 2 boot sectors on Drive 3, but if you managed to find a second one within one of the other dumps than ignore this.

I had assumed the references to negative offsets were DMDE finding records on Drive 3 about Drive 4 and the negative indicated that the offset was "backwards" from the start of Drive 3, back into Drive 4 since the span order was Drive 4 -> Drive 3.

I.E. Each drive has about 15,000,000, 000 sectors so the whole volume would be about 30,000,000, 000, so I thought that something like -11,000,000, 000 on Drive 3 was a record referencing sector 4,000,000, 000 on Drive 4. If that is not at all the case and you're saying you believe the negative offsets are entirely due to DMDE mixing up the original bootsectors and the copies, then please confirm this so we are on the same page. I can easily see how DMDE could be confused as it also has references to sectors like "46,883,627,033" which is way over the drive capacity.

I have uploaded the dumps you requested to the folder:

$Volume 03 15628050458, 15628050459->
"Drive 3 - $Volume 03 Reported End [dev3_lba15628050458_2].bin"

$Volume 02 15628050465 , 15628050466:
"Drive 3 - $Volume 02 Reported End & $Volume 04 Reported Start [dev3_lba15628050465_2].bin"

The reported start of $Volume 04 is the same as the reported end of $Volume 02 (15, 628, 050, 465 ) so that is included in the latter dump, which I believe is what you meant by your instructions.

fzabkar · Aug 17, 2019

~~I think that the negative offsets and large positive offset are due to DMDE mixing up the primary and secondary (copy) boot sectors. ICBW, though.~~

Of course you are correct. All three sectors should have been identified as xCxx, in which case the negative offsets all point to the first disk, and the positive offset is an error due to the misidentification of the sector as Bxxx. <smacks forehead>

That said, I notice that both boot sector copies on drive #3 are identical to sector 264192 on drive #4. I still believe that 15628050465 is the correct copy, but how do we confirm this?

This is how I see the structure of drive #4:

Code:

----------------
partition info
----------------
metadata
---------------- sector a
boot sector
----------------
data part #1
---------------- sector b
metadata ?
----------------
partition info
----------------

… and this is drive #3:

Code:

----------------
partition info
----------------
metadata
---------------- sector c
data part #2
----------------
copy of boot sector
----------------  sector d
metadata ?
----------------
partition info
----------------

AISI, in order to reconstruct the logical 16TB volume (Archive), we need to find sectors a, b, c, d and stitch together the two data parts.

Code:

---------------- sector a
boot sector
----------------
data part #1
---------------- sector b
---------------- sector c
data part #2
----------------
copy of boot sector
----------------  sector d

Sector a is 264192 and sector d is one of the two copies. Now we need to find b and c.

The size of the Archive volume is recorded in the boot sector, namely 31255576568 sectors plus an extra sector for the boot sector copy. That gives us the distance between sectors a and d in the Archive volume.

One possible plan of attack might be to examine the end of the LDM Metadata partition on disk #3 and look for the first data sector. ISTM that the first such sector has an "RCRD"signature. Next I would go to the end of disk #4 and look for data that might belong to the same file, hopefully containing the same signature.

oblivioncth · Aug 17, 2019

fzabkar said:
~~I think that the negative offsets and large positive offset are due to DMDE mixing up the primary and secondary (copy) boot sectors. ICBW, though.~~

Of course you are correct. All three sectors should have been identified as xCxx, in which case the negative offsets all point to the first disk, and the positive offset is an error due to the misidentification of the sector as Bxxx. <smacks forehead>

That said, I notice that both boot sector copies on drive #3 are identical to sector 264192 on drive #4. I still believe that 15628050465 is the correct copy, but how do we confirm this?

This is how I see the structure of drive #4:

Code:

---------------- partition info ---------------- metadata ---------------- sector a boot sector ---------------- data part #1 ---------------- sector b metadata ? ---------------- partition info ----------------

… and this is drive #3:

Code:

---------------- partition info ---------------- metadata ---------------- sector c data part #2 ---------------- copy of boot sector ---------------- sector d metadata ? ---------------- partition info ----------------

AISI, in order to reconstruct the logical 16TB volume (Archive), we need to find sectors a, b, c, d and stitch together the two data parts.

Code:

---------------- sector a boot sector ---------------- data part #1 ---------------- sector b ---------------- sector c data part #2 ---------------- copy of boot sector ---------------- sector d

Sector a is 264192 and sector d is one of the two copies. Now we need to find b and c.

The size of the Archive volume is recorded in the boot sector, namely 31255576568 sectors plus an extra sector for the boot sector copy. That gives us the distance between sectors a and d in the Archive volume.

One possible plan of attack might be to examine the end of the LDM Metadata partition on disk #3 and look for the first data sector. ISTM that the first such sector has an "RCRD"signature. Next I would go to the end of disk #4 and look for data that might belong to the same file, hopefully containing the same signature.

Ok, I get what you are saying but am confused about two things.

1) I'm not totally sure I understand the "drive maps" you provided. I get that the first two are what you believe the structures of the two drives look like now and that the third is what they need to look like in order to have successfully recreated the Volume "Archive", but I'm not positive about what you are referring to as sectors A, B, C, and D. Is the following correct?:

Sector A - First sector of actual data (after metadata) of Volume "Archive" on Drive 4
Sector B - Last sector of actual data of Volume "Archive" on Drive 4
Sector C - First sector of actual data (after metadata) of Volume "Archive" on Drive 3 (continuing the volume from the end of drive 4)
Sector D - Last sector of actual data of Volume "Archive" on Drive 4

Assuming this is correct, I agree Sector A is 264192 as that is clearly noted correctly by DMDE. I'm quite confused about Sector D though. You're saying it is one of the two bootsector copies on Drive 3, but did you find a bootsector copy on one of the sectors you directly asked me to dump? Because like I was saying before the only bootsector copy (and the only bootsector data at all for that matter) that DMDE automatically picked up on Drive 3 was near the very end (I correctly said it was the end before because of a glitch in DMDE that wouldn't let me scroll down), at sector 15 628 052 479. So I just want to clarify where the 2nd copy you are referring to is (?). I'm also confused about the supposed boot sector copy that DMDE found on drive 4 at sector 9 103 920 152. The volume definitely did not end that early so is this possibly due to how the drive was reinitialized?

I do understand what you are saying about sectors B and C. I need to see if I can locate the two halves of data that belong to the same file near the end of Drive 4 and the start of Drive 3 so that we can confirm the offset of the end of 'Archive' on Drive 4 (Sector B) and the start offset of 'Archive' on Drive 3 (Sector C). I will examine the drives and see what I can find, hopefully you are correct about the RCRD signature

In the meanwhile, here is my current understanding of the situation, let me know what I'm getting wrong and am missing (I omitted sections that I am uncertain of):

fzabkar · Aug 17, 2019

ISTM that you are on the same page as me.

As for the strange boot sector at LBA 9103920152, it appears to be an artifact unrelated to the file system. Its contents point to an unlikely partition at offset 02 and size 6173 sectors (3MB). Such bogus boot sectors are often found during a deep scan, and many of them are "templates" incorporated within system files such as format.com, etc. The other boot sectors at the end of the drive are a mystery to me, but one of them could be a remnant from an earlier build.

The following dump contains the LDM Metadata partition on Disk #3 (offsets 0 - 0xFFFFF), plus a portion of your data (offset 0x100000).

Drive_3_-Pre-'Archive'_Metadata(dev3_lba260130_4062).bin

The data begin at sector 262178 (= 260130 + 2048) and consist of 0x1000-byte blocks with an "RCRD" signature. The first RCRD block is at 0x100000 - 0x100FFF.

If you go to the end word (= 2 bytes) of each block, you will see a number which is incremented in each subsequent block. Note that the data are little-endian, ie the least significant byte is stored before the most significant byte, so the bytes need to be swapped to make sense of them.

Code:

Offset     Data
-----------------
0x100FFE   0x75A0
0x101FFE   0x75A1
0x102FFE   0x75A2
...
0x15FFFE   0x75FF
0x160FFF   0x7600
0x161FFF   0x7601
...
0x1FBBFF   0x769B

I would now go to the end of drive #4 (Ctrl-End) and search for "RCRD"

Tools -> Search for String in Object
ASCII = RCRD
Backward
From Cursor
Sector offset = 0
OK

Go to the end of the first RCRD block that you find and hope that you see 0x759F (9F 75). If you are lucky, you will have found sectors b and c (in hexadecimal, 0x759F and 0x75A0 are sequential numbers). Note that the search should only take a minute or so.

Edit:

We appear to have found the $LogFile metadata for the NTFS Archive volume:

https://digital-forensics.sans.org/...is-Impacts-David-Cowen-with-Matthew-Seyer.pdf

It appears to bridge the two halves of the volume.

Here is an interesting article and a useful tool:

https://www.codeproject.com/Tips/1072219/NTFS-LogFile-Parser

oblivioncth · Aug 17, 2019

fzabkar said:
ISTM that you are on the same page as me.

As for the strange boot sector at LBA 9103920152, it appears to be an artifact unrelated to the file system. Its contents point to an unlikely partition at offset 02 and size 6173 sectors (3MB). Such bogus boot sectors are often found during a deep scan, and many of them are "templates" incorporated within system files such as format.com, etc. The other boot sectors at the end of the drive are a mystery to me, but one of them could be a remnant from an earlier build.

The following dump contains the LDM Metadata partition on Disk #3 (offsets 0 - 0xFFFFF), plus a portion of your data (offset 0x100000).

Drive_3_-Pre-'Archive'_Metadata(dev3_lba260130_4062).bin

The data begin at sector 262178 (= 260130 + 2048) and consist of 0x1000-byte blocks with an "RCRD" signature. The first RCRD block is at 0x100000 - 0x100FFF.

If you go to the end word (= 2 bytes) of each block, you will see a number which is incremented in each subsequent block. Note that the data are little-endian, ie the least significant byte is stored before the most significant byte, so the bytes need to be swapped to make sense of them.

Code:

Offset Data ----------------- 0x100FFE 0x75A0 0x101FFE 0x75A1 0x102FFE 0x75A2 ... 0x15FFFE 0x75FF 0x160FFF 0x7600 0x161FFF 0x7601 ... 0x1FBBFF 0x769B

I would now go to the end of drive #4 (Ctrl-End) and search for "RCRD"

Tools -> Search for String in Object
ASCII = RCRD
Backward
From Cursor
Sector offset = 0
OK

Go to the end of the first RCRD block that you find and hope that you see 0x759F (9F 75). If you are lucky, you will have found sectors b and c (in hexadecimal, 0x759F and 0x75A0 are sequential numbers). Note that the search should only take a minute or so.

Edit:

We appear to have found the $LogFile metadata for the NTFS Archive volume:

https://digital-forensics.sans.org/...is-Impacts-David-Cowen-with-Matthew-Seyer.pdf

It appears to bridge the two halves of the volume.

Here is an interesting article and a useful tool:

https://www.codeproject.com/Tips/1072219/NTFS-LogFile-Parser

I'm a hardware engineer by day so I have no issues using Hex when ideal. Lots of good stuff you've figured out, I'll look through it, investigate the data you highlighted and perform that search soon. Been a bit busy since its the weekend but I will have time to investigate these details more tomorrow.

fzabkar · Aug 17, 2019

Sorry, I wasn't aware of your background. I'm an electrical engineer. Usually when I talk hex people throw up their hands and run away screaming.

oblivioncth · Aug 18, 2019

fzabkar said:
Sorry, I wasn't aware of your background. I'm an electrical engineer. Usually when I talk hex people throw up their hands and run away screaming.

Haha its alright, you would have had no way of knowing before hand. Its better to play it safe when supporting people you're not very familiar with any way so I don't blame you.

Have to hit the hay soon (it's 1:27 AM here, I sense you may be in a significantly different timezone), but I'm looking through both drives and the link you provided (some of the authors explanation confuses me but I'm working through it) to see if I can dump the entire NTFS logfile.

oblivioncth · Aug 18, 2019

Alright here is where we are at currently. I haven't tried any of python tools you linked and will give them a roll when I have more time later, but for now the page helped me piece together the $Logfile for the 'Archive' Volume. I'm confident I got it correctly because it is exactly 64 MB.

I moved everything to a Google Drive folder and added a spreadsheet with the notes I was using while studying the logfile blocks. There is weird jumping of the value that you first found to increment by 1 each 4096/0x1000 bytes ever so often (I think this is part of the LSN, possibly the sequence number), but that might be totally normal, I'm not sure. This is clearly indicated within the spreadsheet.

Since it the $Logfile is supposed to be contiguous the entries in the table that mark where it ends on Drive 4 and where it starts again on Drive 3 are most likely Sector markers B & C that we discussed before, so we might not even need to make use of the file itself to recreate the archive.

The summary of where each file portion is located on each drive is noted in the "Full" tab of the spreadsheet.

The spreadsheet itself is in the "Documentation" folder, while $Logifile.bin is in the "Data\Identified Files" folder.

https://drive.google.com/open?id=11NHLMjoj4MI5E9NiVrFkoCMxzOGdwXnX

fzabkar · Aug 18, 2019

As you say, the log file is contiguous, so we now know a, b, c and d (d can be computed from the size of the volume, namely 31255576568 + 1).

So now ...

launch DMDE
Drive -> Construct RAID
select JBOD/Spanned from drop-down list
Menu -> Add Disk -> Drive #4
r-click disk -> Partition / Offset / Segment
First Sector = a
Last Sector = b
OK
Menu -> Add Disk -> Drive #3
r-click disk -> Partition / Offset / Segment
First Sector = c
Last Sector = d
OK
OK

DMDE should now display your 16TB spanned Archive volume. Double-clicking it should then bring up your file/folder tree.

I would now navigate to a file which you know to be on the second disk, preferably an image file such as JPEG, GIF, BMP, etc.

Locate this file in the top right hand pane, r-click it and select "Recover file_name". Then recover it to another drive.

Verify that this file displays correctly in your image viewer. This will confirm that the two halves of the spanned volume have been correctly stitched together.

At this point I would recover all your files to two or more drives. The freeware version of DMDE only recovers a limited number, so you'll have to pay US$20 for the basic version. I am not aware of any other freeware that can do this for you.

As for rebuilding the metadata, I think we would both need to be very careful. I am doing this for the first time, with no real knowledge of dynamic volumes, so I don't trust myself. In any case we have no working example to compare against, so I am loathe to continue down this path.

oblivioncth · Aug 19, 2019

I confirmed the sectors I noted, calculated D, and loaded up the volume in the fashion you instructed me to. All signs point to the sectors having been correct as I no longer got the "Volume does not fit onto device error", but did if I decreased the end sector on the 2nd drive by just 1 sector (so we got it exactly correct). Additionally, I am able to now see what I beleive to be everything, and double checked that I am able to see some files that I was working with the day before this happened that are not present if I just mount Drive 4 alone in DMDE. Furthermore, I recovered a 3.73GB ROM backup that was on Drive 3 (one of the files that didn't show up before with just Drive 4) and re-ripped the disk from my closet and then compared the files by-byte in HxD and they came back identical, which suggests everything was mapped correctly.

So in theory I have access to all my data (other than the possibility of a few files being corrupted due to the initialization (not a big deal). It MAY be possible if I distribute them across all free space on all other drives on all other machines at my residence that I can fit all of the data from this volume elsewhere temporarily and then reformat and move it all back; though, it would certainly be a long and tedious task.

Given that DMDE provided with the right bounds of the volume is able to mount the NTFS volume correctly and access ~100% of the data, you would think there would be a similar tool available that is able to write the metadata for that enumerated "virtual" volume to the disk itself and restore it to a state where Windows can see it and then the rest of the work can be done by chkdsk via the journaling of NTFS.

I understand your hesitation, especially with no example to use (finding anything about the LDM database windows uses on Google appears to be a fools errand), so unless you have any ideas that, while they may be unlikely to succeed, would be an "easy fix" (relatively speaking of course haha) I'm fine stopping here and trying to find somewhere to put all this data temporarily. You've helped me more than enough at this point. It's just a shame that in theory it seems very possible given DMDEs ability to read the volume as I said, but alas fixing a unique volume by hand is much more of a challenging than an automated tool performing a specific task (not to mention one that I'm sure has been developed for quite some time by specialists).

fzabkar · Aug 19, 2019

I know how to edit the GPT info on a single drive, but I have no idea how to edit the same info on a spanned volume. I would think that each disk would need to store start sector, end sector and capacity info for both disks, but we have no reference to use as a template. It's a shame because we're so close. I don't have any spare drives to experiment with, either.

Anyway, I learned a lot. Thanks for indulging me. If you manage to find some spare drives for experimentation (even 100GB or less might be adequate, dissimilar would be better), we could always investigate further.

fzabkar · Aug 19, 2019

I'm wondering if we just need to adjust the 128-byte record corresponding to the LDM Data partition at sector 2. I guess we couldn't make matters any worse if we were to edit this record incorrectly. We wouldn't be touching the data area, and if we got it wrong, Windows wouldn't mount the spanned volume.

To this end, could you dump sector ranges 0 - 33 on each drive? This will be the partitioning info.

Could you also tell us the values that you used for a, b, c and d?

oblivioncth · Aug 19, 2019

fzabkar said:
I'm wondering if we just need to adjust the 128-byte record corresponding to the LDM Data partition at sector 2. I guess we couldn't make matters any worse if we were to edit this record incorrectly. We wouldn't be touching the data area, and if we got it wrong, Windows wouldn't mount the spanned volume.

To this end, could you dump sector ranges 0 - 33 on each drive? This will be the partitioning info.

Could you also tell us the values that you used for a, b, c and d?

Well hey, no one can ever say you didn't try!

While I don't have any spare drives that really help at all in terms of recovering 12TB of data, now that I think about it, I do believe I have 2 spare 120GB drives that I can zero and then create a 240GB spanned volume with on another Windows 10 Machine so that we have a perfect example of a working spanned GPT NTFS volume across 2 disks that only contains data required for the volume to work. I will have to double check later tonight when I get home.

For now, here is everything else you've asked for:

Drive 4:
Sector A - 264 192
Sector B - 15 628 052 479

Drive 3:
Sector C - 262 178
Sector D - 15 628 050 458

Some notes on this... Sector A I based off the reported start in DMDE that absolutely seems to be correct, and sectors B and C I based on the last sector of $Logfile on Drive 4 and the first sector of $Logfile on Drive 3 respectively (which I'm 99% sure I checked correctly). D was then calculated using the reported size of the volume that you found, 31 255 576 568 + 1. Assuming that reported size is correct, everything seems to work out as the value I got for sector D is the exact reported end for $Volume 03 in DMDE. Though, you did suspect that $Volume 02 was actually the correct end, and there is an odd discrepancy related to this in my scratch notes:

Code:

Drive 4
Start: 264 192
End: 15 628 052 479

Drive 3:
Start: 262 178
End: X = 15 628 050 458

Specific:

31255576569 = (15628052479 - 264192 + 1) + (X - 262178 + 1)
31255576569 = 15627788288 + (X - 262177)
15627788281 = X - 262177
X = 15628050458 (This matches the reported end of $Volume 03 in DMDE Exactly)

Size on Disk 4: 15 627 788 288
Size on Disk 3: 15 627 788 280 (8 Sectors less than on Disk 4, if this was increased by 8 sectors to match, the new end of disk 3 would be 15 628 050 466, which is equal to the reported end of $Volume 02 + 1.

So, I suppose it is possible that the reported volume is slightly off and that the actual end of the volume is 15 628 050 465 (or 15 628 050 466?). The fact that the total size I used to calculated D does account for the bootsector copy and lines up exactly with the reported end of $Volume 03, while matching the Volume segment sizes on both disks would be off by 1 for $Volume 02 makes me think its more likely The value for D I calculated is the correct one. Furthermore, if you compare the dumps of the ends of each "volume" found in DMDE you had me provide before:

Drive 3 - $Volume 03 Reported End[dev3_lba15628050458_2]

and

Drive 3 - $Volume 02 Reported End & $Volume 04 Reported Start[dev3_lba15628050465_2]

you will find that they are actually identical. So it seems that for whatever reason there is the same metadata marker for the end of the volume repeated twice back to back. If the slightly longer end was used instead (15 628 050 465) that would mean there would be metadata info in what would then be the data section of the volume, which wouldn't make sense.

In case the first end marker was put there due to whatever operation corrupted the volume metadata, I looked at the sectors between 15 628 050 458 and 15 628 050 465 (now I see that they are both marked as "NTFS Boot (copy)" in DMDE so duh, those are what you were talking about when referring to the two copies on Drive 3, sorry about that) and it is completely filled with zeros. So, even if the true end had been the latter sector, there is no harm in using the first end marker 15 628 050 458 (which I'm pretty sure is correct anyway from the calculation) as no data is lost since the section that is omitted is blank. I can only see this being an issue if for some reason the LDM (though we would be editing that anyway) expects the last sector to be in a particular spot due to some kind of checksuming or the like, other than the volume size itself.

I am still a bit curious as to why the second half of the volume would be 8 sectors smaller than the first half when both disks are the same exact size and model, but the size of the volume is reported to be exactly the same, 31 255 576 568 (+1) , in the bootsector at sector 262 178 on Drive 4 and both of its copies (15 628 050 458/15 628 050 465) on Drive 3 so I trust that it is correct. And, if it is correct and the sectors I determined for B & C are correct (which I'm very certain of) then "because math" the end of the volume MUST be sector 15 628 050 458 on Drive 3. So even despite the size discrepancy my bet is that 15 628 050 458 is the correct value for Sector D.

Sorry for the length of this, but I just wanted to make sure you were made aware of every detail.

The 0-33 sector dumps for each drive are in the Google Drive folder "Data\RAW\LDM Repair".

fzabkar · Aug 19, 2019

Here is the current state of the partition info for the LDM data partition:

Drive 4 - Start (Partition Info) [dev4_lba0_34].bin

Code:

Offset(h) 00       04       08       0C

00000500  A0609BAF 3114624F BC683311 714A69AD
00000510  F277DC9B FCF0AC4C B6C1CDB0 E5A09A07
00000520  22000400 00000000 8E2A81A3 03000000
         ^^^^^^^^^^^^^^^^^ *****************
         start sector      end sector

00000530  00000000 00000000 4C004400 4D002000  ........L.D.M. .
00000540  64006100 74006100 20007000 61007200  d.a.t.a. .p.a.r.
00000550  74006900 74006900 6F006E00 00000000 t.i.t.i.o.n.....

Drive 3 - Start (Partition Info) [dev3_lba0_34].bin

Code:

Offset(h) 00       04       08       0C

00000500  A0609BAF 3114624F BC683311 714A69AD
00000510  1C282BC1 7924AA42 B10B1B4D FE8EA727
00000520  22000400 00000000 8E2A81A3 03000000
         ^^^^^^^^^^^^^^^^^ *****************
         start sector      end sector

00000530  00000000 00000000 4C004400 4D002000  ........L.D.M. .
00000540  64006100 74006100 20007000 61007200  d.a.t.a. .p.a.r.
00000550  74006900 74006900 6F006E00 00000000 t.i.t.i.o.n.....

We need to edit the above "initialised" partition data to reflect the actual LDM partitions.

Code:

Drive 4
Start: 264 192 = 0x40800
End: 15 628 052 479 = 0x3A38127FF

Drive 3:
Start: 262 178 = 0x40022
End: X = 15 628 050 458 = 0x3A381201A

So I propose that the original data should be ...

Drive 4 - Start (Partition Info) [dev4_lba0_34].bin

Code:

Offset(h) 00       04       08       0C

00000500  A0609BAF 3114624F BC683311 714A69AD
00000510  F277DC9B FCF0AC4C B6C1CDB0 E5A09A07
00000520  00080400 00000000 FF2781A3 03000000
         ^^^^^^^^^^^^^^^^^ *****************
         start sector      end sector

00000530  00000000 00000000 4C004400 4D002000  ........L.D.M. .
00000540  64006100 74006100 20007000 61007200  d.a.t.a. .p.a.r.
00000550  74006900 74006900 6F006E00 00000000 t.i.t.i.o.n.....

Drive 3 - Start (Partition Info) [dev3_lba0_34].bin

Code:

Offset(h) 00       04       08       0C

00000500  A0609BAF 3114624F BC683311 714A69AD
00000510  1C282BC1 7924AA42 B10B1B4D FE8EA727
00000520  22000400 00000000 1A2081A3 03000000
         ^^^^^^^^^^^^^^^^^ *****************
         start sector      end sector

00000530  00000000 00000000 4C004400 4D002000  ........L.D.M. .
00000540  64006100 74006100 20007000 61007200  d.a.t.a. .p.a.r.
00000550  74006900 74006900 6F006E00 00000000 t.i.t.i.o.n.....

You would need to make the same changes to the backup copies of each sector at the end of each drive.

I hope this is all that we need to do. Good luck.

https://en.wikipedia.org/wiki/GUID_Partition_Table

800px-GUID_Partition_Table_Scheme.svg.png

Question Windows 10 Spanned Volume Suddenly Missing (Dynamic Disks: "Invalid")

Distinguished

Judicious

Distinguished

Judicious

Distinguished

Judicious

Distinguished

Judicious

Distinguished

Distinguished

Judicious

Distinguished

Judicious

Distinguished

Judicious

Distinguished

Judicious

Distinguished

Distinguished

Judicious

Distinguished

Judicious

Judicious

Distinguished

Judicious

Share this page