Question I need help with repairing a spanned volume ?

[Greywolf74]

I have a PC set up as home file server running Windows 11 Pro. I have a total of 8 HDDs, 4 of which are spanned into a single volume and the other 4 are also spanned in to a single volume for the purpose up backing up the first spanned volume. (if its relevant, I have 6 of them plugged into the MoBo and 2 of them plugged in to a PCIe expansion card). My OS is installed on 2 NVMe drives that are running in raid 1 if that is helpful.

Today i took a 1TB SSD that I had laying around and popped it in an external hard drive and and used it to copy a few hundred MBs of data to the file server. After I was done I noticed the external drive had an active boot partition on it from the PC it was previously installed in. I loaded up Acronis Disk Director 12 in order to delete the active partition and reclaim the wasted 500MB. After I was done when I rebooted and got back in to windows and I noticed that the active partition was still there so I went to load up Acronis again to try and remove it again. When Acronis loaded this time it said it could not find/access any drives on the machine. I tried relaunching Acronis a couple of times, each time with the same error message. So I took the external hard drive and the Acronis disk to another computer and was able to remove the active partition on that drive like I originally wanted to. When I went back over to my windows machine to transfer some more files to the external I noticed neither of my spanned volumes where showing in Windows. I went to disk management and I can see the disks there, but all 8 of them say invalid and when I try to reactive them I get an error saying something to the effect of "this operation is not allowed on the invalid disk pack". Is there anyway to reconnect the spanned volumes so that I dont lose my whole life that is stored on this computer?

P.S. I did try rolling windows back to an earlier restore point hoping that the issue was in the registry or something but that did not fix the issue. I have not tried anything else apart from disconnecting all the drives, rebooting, shut down, reconnected drives, and then booted in to windows again. Im afraid to do much of anything else for fear of permanently loosing my data.

 

[USAFRet]

Is there anyway to reconnect the spanned volumes so that I dont lose my whole life that is stored on this computer?

Rebuild whatever config you have, and recover the full data set from your backup.

But I'm assuming you don't have that backup, correct?

 

[Greywolf74]

Rebuild whatever config you have, and recover the full data set from your backup.

But I'm assuming you don't have that backup, correct?

Correct, the back up volume had the same thing happen to it that the primary volume had happen. Otherwise, Id have already done that.

 

[USAFRet]

Correct, the back up volume had the same thing happen to it that the primary volume had happen. Otherwise, Id have already done that.

Exactly.
A real backup should be completely unaffected by what happens on the primary system.

Spanned and/or RAID 1 is rarely a good idea for data security, especially in the consumer space.


I am 100% unsure how to "fix" this.
Possibly someone else will chime in.

 

[Greywolf74]

Exactly.
A real backup should be completely unaffected by what happens on the primary system.

Spanned and/or RAID 1 is rarely a good idea for data security, especially in the consumer space.


I am 100% unsure how to "fix" this.
Possibly someone else will chime in.

Yes, I understand that. I normally keep an external back up as well but I lost a hard drive the other day in one of the spanned volumes so I stupidly took the external back up drive and used it to replace the failed drive in the PC. I then in turn ordered another large hard drive to to my external back ups to and its just dumb luck that this happens in the short time Im waiting for the replacement drive to arrive. 🙁

 

[Darkbreeze]

I don't see much of any way to fix it either, which is exactly why this type of configuration is generally unwanted and why you should ALWAYS have your data in at least two, and MUCH preferably THREE, locations, at all times. Because clearly losing two copies of data CAN happen, as uncommon as it might seem.

Another external drive, and additional internal drive, cloud storage, heck, even periodically just spanning it all to a series of DVD or BD discs and sticking them away somewhere makes for compelling insurance. Had you done that you would not be having this conversation now and discs are much cheaper than, well, any even possible option for recovering that data which usually doesn't work out like it does in the movies anyhow. Sucks, but, a third copy would have eliminated this "bad luck" from being a problem.

 

[Greywolf74]

As I previously stated, Im aware of this and I normally do have two back ups and I stupidly used the drive from the external back up to repalce a failed drive in one of the spanned volumes thinking "what could possibly go wrong in the week that it takes to buy a new drive from Newegg?". Again, Im painfully aware of how stupid that was but Ive had this file server going for 12 years now and Ive never lossed both volumes at the same time so I mean what are the odds? I could have hit the lotto but nope, instead this happened during the 1 week I dont have a second back up O __ o

 

[fzabkar]

Can you show us the Partitions tabs for each drive in DMDE? This should tell us what happened.

https://dmde.com/

DMDE can stitch together a spanned volume, but we may need to tell it the starting and ending LBAs of each member of the array.

 

[Greywolf74]

Ive never used DMDE before but I believe this is what you were asking for. I only did the 4 drives for one of the volumes. I figured as long as I can stitch one back together then I can rebuild the other one and copy the data back over to it.

3TB hosted at ImgBB

Image 3TB hosted in ImgBB

ibb.co

4TB hosted at ImgBB

Image 4TB hosted in ImgBB

ibb.co

6TB hosted at ImgBB

Image 6TB hosted in ImgBB

ibb.co

DMDE-12-TB hosted at ImgBB

Image DMDE-12-TB hosted in ImgBB

ibb.co

 

[fzabkar]

ISTM that the 4TB HDD may be the first member of the span. If you d-click the Main NTFS volume, do you see your file/folder tree?

What do you see if you d-click Main Storage on the 3TB drive?

https://i.ibb.co/QYJMNKp/4TB.png
https://i.ibb.co/HVXRZ3t/6TB.png
https://i.ibb.co/txjHncb/3TB.png
https://i.ibb.co/JdjqY9S/DMDE-12-TB.png

 

[Greywolf74]

I can see the file trees on both drives (pics linked) the other two drives want to detect FS parameters.

4-TB-File-tree hosted at ImgBB

Image 4-TB-File-tree hosted in ImgBB

ibb.co

3-TB-file-tree hosted at ImgBB

Image 3-TB-file-tree hosted in ImgBB

ibb.co

 

[fzabkar]

I'm confused now. I was expecting that only the first drive would have a file system. I had intended to stitch all the drives together to create a single 25TB virtual NTFS volume, but now I don't know how to proceed.

https://i.ibb.co/HNXW1DH/4-TB-File-tree.png
https://i.ibb.co/qxfHvrc/3-TB-file-tree.png

Edit:

See if DMDE will Auto Calculate the parameters of a JBOD/Span consisting of your 3TB and 12TB drives. It should then present you with a virtual 15TB NTFS volume from which you could then r-click and Recover your files (to another drive).

 

[Greywolf74]

I'm confused now. I was expecting that only the first drive would have a file system. I had intended to stitch all the drives together to create a single 25TB virtual NTFS volume, but now I don't know how to proceed.

https://i.ibb.co/HNXW1DH/4-TB-File-tree.png
https://i.ibb.co/qxfHvrc/3-TB-file-tree.png

Edit:

See if DMDE will Auto Calculate the parameters of a JBOD/Span consisting of your 3TB and 12TB drives. It should then present you with a virtual 15TB NTFS volume from which you could then r-click and Recover your files (to another drive).

DMCE is read only yes? Wont hurt anything if it doesnt work correct?

What about the 6TB drive?

I have almost everything pulled of of the 4TB anyway using Get data back pro. GDB pro will also recover files from the 3TB. It wants to run partition scans on the 6 and 12TB scans. Havent done it yet, havent gotten that far.

 

[fzabkar]

DMDE is read-only. It incorporates a disc editor, but you have to willfully ignore DMDE's warnings in order to write to the source drive.

The 6TB and 12TB drives are a problem because their file systems are on another drive. Therefore your tools are restricted to "file carving", ie they identify files by their headers rather than file system metadata. That's why I suggested that you try assembling a virtual 15TB volume using the 3TB and 12TB drives. The file system on the 3TB drive may point to data on the 12TB drive.

 

[Darkbreeze]

now I don't know how to proceed.

Well, that makes for THREE of us then.

 

[Greywolf74]

DMDE is read-only. It incorporates a disc editor, but you have to willfully ignore DMDE's warnings in order to write to the source drive.

The 6TB and 12TB drives are a problem because their file systems are on another drive. Therefore your tools are restricted to "file carving", ie they identify files by their headers rather than file system metadata. That's why I suggested that you try assembling a virtual 15TB volume using the 3TB and 12TB drives. The file system on the 3TB drive may point to data on the 12TB drive.

Ok, Ive got the scan running for those two drives.

Sorry, still unclear on why were not trying to rebuild the entire volume like this? If the 6 and 12TB drives have their file systems on another drive wouldnt the best chance for reconstruction be to scan all the drives together? Im a bit of a power user but Im no expert so Im just curious.

 

[fzabkar]

An NTFS volume begins with a boot sector. This sector contains a BIOS Parameter Block (BPB). The BPB contains information such as the size of the volume, cluster size, etc.

In your case there is a "25TB boot sector" on the 4TB drive, and a "15TB boot sector" on the 3TB drive. The file system metadata live at around the 3GB - 4GB point on the first drive in the volume. This means that the $MFT metafile (which contains the file and folder names for the whole volume) lives on the first drive in that particular volume.

Firstly, I don't understand why there is a 15TB NTFS volume (= 3TB + 12TB) in addition to a 25TB volume (= 4TB + 3TB + 6TB + 12TB).

Secondly, since you were able to recover original file names from your 3TB drive, this suggests that you could recover the file names of the files on the 12TB drive by using the file system metadata on the 3TB drive. Otherwise, if you scan the 12TB drive on its own, you will not only lose the original file names (which are in the $MFT metafile on the 3TB drive), but you will have no way of reconstructing a fragmented file.

At least, that's the way it looks to me. But I don't understand it ...

 

[Greywolf74]

An NTFS volume begins with a boot sector. This sector contains a BIOS Parameter Block (BPB). The BPB contains information such as the size of the volume, cluster size, etc.

In your case there is a "25TB boot sector" on the 4TB drive, and a "15TB boot sector" on the 3TB drive. The file system metadata live at around the 3GB - 4GB point on the first drive in the volume. This means that the $MFT metafile (which contains the file and folder names for the whole volume) lives on the first drive in that particular volume.

Firstly, I don't understand why there is a 15TB NTFS volume (= 3TB + 12TB) in addition to a 25TB volume (= 4TB + 3TB + 6TB + 12TB).

Secondly, since you were able to recover original file names from your 3TB drive, this suggests that you could recover the file names of the files on the 12TB drive by using the file system metadata on the 3TB drive. Otherwise, if you scan the 12TB drive on its own, you will not only lose the original file names (which are in the $MFT metafile on the 3TB drive), but you will have no way of reconstructing a fragmented file.

At least, that's the way it looks to me. But I don't understand it ...

Ok, thanks for the info. It looks like this is going to be running all night so once its done Ill let ya know what happens.

 

[Darkbreeze]

Keep in mind, just because you are able to recover the file names, and the structure, does NOT mean the data itself is still available to be recovered or that even if it is, it will be without damage. Very unlikely to be the case. Possible, I suppose, but highly improbable.

 

[Greywolf74]

An NTFS volume begins with a boot sector. This sector contains a BIOS Parameter Block (BPB). The BPB contains information such as the size of the volume, cluster size, etc.

In your case there is a "25TB boot sector" on the 4TB drive, and a "15TB boot sector" on the 3TB drive. The file system metadata live at around the 3GB - 4GB point on the first drive in the volume. This means that the $MFT metafile (which contains the file and folder names for the whole volume) lives on the first drive in that particular volume.

Firstly, I don't understand why there is a 15TB NTFS volume (= 3TB + 12TB) in addition to a 25TB volume (= 4TB + 3TB + 6TB + 12TB).

Secondly, since you were able to recover original file names from your 3TB drive, this suggests that you could recover the file names of the files on the 12TB drive by using the file system metadata on the 3TB drive. Otherwise, if you scan the 12TB drive on its own, you will not only lose the original file names (which are in the $MFT metafile on the 3TB drive), but you will have no way of reconstructing a fragmented file.

At least, that's the way it looks to me. But I don't understand it ...

Ok, so I accessed that volume and copied all of the data off of it however the overwhelming majority of it is incomplete or corrupt. I had it put all the bad files in a bad files folder. The bulk of what was recovered was in that folder.

 

[Darkbreeze]

Ok, so I accessed that volume and copied all of the data off of it however the overwhelming majority of it is incomplete or corrupt.

That's about what I figured would be the case, unfortunately.

 

[Greywolf74]

An NTFS volume begins with a boot sector. This sector contains a BIOS Parameter Block (BPB). The BPB contains information such as the size of the volume, cluster size, etc.

In your case there is a "25TB boot sector" on the 4TB drive, and a "15TB boot sector" on the 3TB drive. The file system metadata live at around the 3GB - 4GB point on the first drive in the volume. This means that the $MFT metafile (which contains the file and folder names for the whole volume) lives on the first drive in that particular volume.

Firstly, I don't understand why there is a 15TB NTFS volume (= 3TB + 12TB) in addition to a 25TB volume (= 4TB + 3TB + 6TB + 12TB).

Secondly, since you were able to recover original file names from your 3TB drive, this suggests that you could recover the file names of the files on the 12TB drive by using the file system metadata on the 3TB drive. Otherwise, if you scan the 12TB drive on its own, you will not only lose the original file names (which are in the $MFT metafile on the 3TB drive), but you will have no way of reconstructing a fragmented file.

At least, that's the way it looks to me. But I don't understand it ...

Just FYI, I told DMDE to recover all 4 drives in the volume which it was able to virtually rebuild 3 of the 4. This allowed me to recover about 98% of my data. Im trying the same thing on my other volume now. Maybe I can get it all back but even if I cant Im pretty happy just being able to recover the vast majority of it. Thank you for all your help.