| Author | Message | ||
     Victor Kovacs Username: vickov Registered: N/A |
Lately both of our Expanded RAID units crashed and I managed to recover all the files from one unit. The other unit is 2.7 TB expanded container. Using WinHex 14.8SR-5 I try to do a recovery by opening the Physical Media: either HD1: Promise 7 Disk RAID5 (1.4TB,iSCSI) or HD2: Promise 7 Disk RAID5 (1.4TB, iSCSI). I receive the following message "Traces of a 2.7TB (5879660544 Sectors) NTFS partition found in sector 63. Size not plausible. Will not be added to partition list. My question is how can I have this partition added to the list or how can I recover this partition? | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
You would need to reconstruct the RAID with Specialist | Reconstruct RAID System. If successful, you can open the partition, and only then the data in that partition is readable correctly. | ||
| Victor Kovacs Username: vickov Registered: N/A |
Looked at the RAID Reconstruct and there seems to be some information missing from the initial question. There are 2 containers with 7 drives in each container in RAID5 (to respect the 2TB limit in NTFS). These two containers are spanned in to one Dynamic volume. So WinHex sees the 2.7TB volume, it's just that it will not display. There must be a way to display. | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
Sorry, I don't understand, neither all technical terms nor the grammar, for example - what it is that WinHex will not display - what a container is that is "spanned in to one" dynamic volume No offense meant, I really don't understand. | ||
| Victor Kovacs Username: vickov Registered: N/A |
Sorry it toke a while to get back to you. Okay so we have a 15 disk Promise Storage unit and we are using 250GB drives. 7 drives (Disk0 to Disk6) are setup in a RAID 5 configuration giving us 1.4TB, call this DISK0. Then the other 7 drives (Disk7 to Disk13) are also setup in a RAID 5 configuration giving us 1.4TB, call this DISK1. Disk14 is the Global hot spare. This was setup because of the 2TB limit in Windows. The disks are dynamic disks and show up in Disk Manager as separate disks of 1.4TB (DISK0 and DISK1) in Win2003. What we did was create a 2.8TB partition, spanned across both disks. X-ways Forensic and WinHex can see the two disks separately, but do not show any partitions thus no mapping. This could be normal given the “Spanned” aspect of the structure. When we try to reconstruct the RAID system, since X-ways only sees 2 large disks (the 2 containers), it wants to add another disk because it knows that a RAID5 is only possible with a minimum of 3 disks. I think that if we would be able to stitch those 2 containers together in WinHex, like the operating system did, then we would be able to see some mappings. We will try to do some reverse engineering on this by creating a “Dynamic Volume” with 2 disks in windows and try to see in WinHex what has been changed and where. Meanwhile, if you have any info for us, it would be greatly appreciated. | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
> This could be normal given the “Spanned” aspect of the structure. Hm... no, usually X-Ways Forensics recognizes "dynamic" disks automatically. You can see the detected partitioning style (e.g. MBR, GPT, or LDM=dynamic) in the caption line of the directory browser. A dynamic disk is checked for dynamic volumes listed in the LDM database. It looks like X-Ways Forensics did not find any dynamic volumes, and it only found traces of a 2.7 TB NTFS volume when it routinely checked sector 63. > When we try to reconstruct the RAID system [...] That functionality is for hardware RAIDs, level 0 and 5, and has nothing to do with dynamic disks or dynamic volumes whatsoever and cannot possibly be of any help with dynamic disks or dynamic volumes. > I think that if we would be able to stitch those 2 > containers together in WinHex, like the operating system > did, then we would be able to see some mappings. No. I understand that what are referring to as containers now are DISK0 and DISK1 (the two RAIDs). Concatenating these two RAIDs won't do any good. The dynamic volume does not start with sector 0 on DISK0 and it does not continue with sector 0 on DISK1. If you wish to access the dynamic spanned volume although Windows and X-Ways Forensics do not detect it any more, you need to concatenate the data that starts at sector 63 on DISK0 and the data that starts at sector y on DISK1 (where very possibly y is also simply 63). Or alternatively it might help to fix the LDM database that is located in the last 1 MB at the end of both DISK0 and DISK1 and that might be corrupt (and quite possibly one copy is intact and could be copied over the corrupt one). | ||
| Danny O'Grady Username: azurlake Registered: N/A |
Huh, I've got a question... The RAID5 I'm working on is a software drive, but I just set an offset of 532304 sectors in each drive (skipping the system partition) and the data seems to be OK; the resulting "unpartitioned space" has long blocks of concatenated data... is that OK? Or it won't work? There's still the problem of getting the file system, I know... | ||
| Alfons Kramer Username: admin3 Registered: 4-2004 |
This is a sort of layering violation. The RAID5 construction is before and independent of the partitioning. The offset's purpose is to skip RAID header information. With software RAID's this will most likely be zero. So please restart your RAID5 reconstruction with zero offsets. In case the system partition is not part of the RAID, you have to consider RAID reconstruction from logical drives (partitions) instead - but this is not the way it should be. |