When we discussed data recovery from RAIDs, we assumed that we already knew the RAID parameters. However, in some cases we do not know the parameters of the RAID to be reconstructed. How do you find the required parameters? RAID vendors can help you with their default values, but sometimes the parameters were customized and are now unknown. Can R-Studio help in this case? Yes, we can use either automatic RAID parameter detection, or the built-in Text/hexadecimal editor to analyze data in RAID components for the purpose of finding its parameters. In this article we will show you how to do this, using a simple NTFS RAID 5 as an example. The article Automatic RAID Parameter Detection explains how to find RAID parameters automatically

Such a task requires at least a basic knowledge of RAID data structures and file systems. If necessary, you may find some useful information on these Web sites.
RAIDs: http://en.wikipedia.org/wiki/RAID
NTFS basics: http://en.wikipedia.org/wiki/NTFS
NTFS in depth: http://technet.microsoft.com/en-us/library/cc758691.aspx

So, let's try to find the required parameters for a simple unknown RAID 5.

Its known parameters are:
1. Number of disks: Three
2. File System: NTFS (created by Windows XP/2003 and later using a standard Master Boot Record (MBR start block)
3. Type: Basic volume

Its unknown parameters that must be found are:
1. Disk order
2. Block size 3
3. Block order
4. Disk offset

The RAID disks are represented as image files created in R-Studio:
Disk1.arc
Disk2.arc
Disk3.arc

Click image to enlarge
Image files of RAID components

Please note that even though R-Studio has found a Disk1 object on Disk2.arc, that does not necessarily indicate that this is the first disk in the RAID.


Finding Master Boot Record
First we need to find the MBR to determine a RAID offset.
1. One after another, open all the tree image files in the Text/hexadecimal editor.
2. Do not enable write to prevent accidental data corruption in the objects being edited!
3. Write down the Windows disk signature for each object to recognize later which Editor's window belongs to which object.
4. Search for the MBR start block. On the Search dialog box, enter 33 C0 8E D0 BC (this is a standard MBR start block, but in some cases it may be different) into the HEX field; then select From start position and enter 0 in Search at offset.
5. Click OK to start searching.

Data in Search dialog box to begin search for the Master Boot Record (MBR)

Search results:

Click image to enlarge
Disk1.arc opened in the Text/hexadecimal editor


Click image to enlarge
Disk2.arc opened in the Text/hexadecimal editor. MBR pattern found.


Click image to enlarge
Disk3.arc opened in the Text/hexadecimal editor. MBR pattern found.

The result is that the Text/hexadecimal editor finds this pattern at address 00 on Disk2.arc and Disk3.arc; Disk1.arc shows only zeros. That means that the offset is 0, and Disk1.arc cannot be the first disk in the RAID.

Meanwhile, the Editor correctly recognized those patterns on Disk2 and Disk3 as master bootstrap loader code. In our case, two disks have the same MBR data on the same place.

Now, as a second step, we need to find the NTFS boot sector.
Take a look on the Sectors preceding partition field on the Template pane

Click image to enlarge
Template pane for Disk2 and Disk3

For our case, the sector preceding the partition is 16,065.

If this value is larger than 63, we should divide it by N -1, where N is the number of disks (in our case, N = 3), which gives us 8,032. This is an approximate position to start searching for the NTFS boot sector. We will start the search from this position to avoid finding false NTFS boot sectors that may remain from previous NTFS partitions.

Jump to that sector in the Editor and then search for the NTFS boot sector pattern.

Click image to enlarge
The Sectors search field in the Text/hexadecimal editor


On the Search dialog box, enter EB 52 90 4E 54 46 53 20 20 20 20 (the NTFS boot sector always starts from these bytes) into the HEX field, select From current position and enter 0 in Search at offset.

Click image to enlarge
Data in Search dialog box to start search for NTFS boot sector

The Editor finds this pattern at sector 8064 on Disk2 and Disk3.

Now select the Boot sector NTFS pattern on the Template pane.

Click image to enlarge
Disk2.arc opened in the Text/hexadecimal editor. NTFS boot sector pattern found. The same pattern is found on Disk3.arc.

Required parameters that we have found
Bytes per sector: 512
Sectors per cluster: 8
Logical Cluster Number for the file $MFT: 786432

Previously found parameters:
RAID offset: 0

Next we need to find the MFT (master file table) on the disk:

1. We will try to find an approximate MFT offset from the RAID start:
MFT offset from the partition start in sectors = Logical Cluster Number for the file $MFT * Sectors per cluster+RAID offset = 786,432*8+0 = 6,291,456
If the RAID offset is not 0, we need to add the offset to the result of the equation above.
MFT start on the first disk = MFT offset from the partition start in sectors/(N-1) = 6,291,456/2 = 3,145,728

2. We will begin to search for the exact MFT start at a position a couple thousand sectors less than this value. Say, sector 3,140,000.
On the Search dialog box, enter "FILE" into the ANSI field, then select From current position and enter 0 in Search at offset.

Click image to enlarge
This pattern is found at sector 10,241,463 on Disk2 and at sector 3,153,792 on Disk3.


Click image to enlarge
First file record sector in Disk3. Start of a data block.

What is important: The signature FILE ends with 0, which means that the file record number is not overwritten with a fixup. If it had ended with * (FILE*), we would not have been able to proceed further in our search and would have needed to use another technique.

The pattern $.M.F.T. (HEX 24 00 4D 00 46 00 54) shows that this is a correct MFT beginning.
Because sector 3,153,792 is closer to our expected value of sector 3,145,728 than to sector 10,241,463, we may assume that Disk3 is the first disk in the RAID.

To proceed further, we need to keep in mind that a file record in MFT occupies two sectors, and that data is written to a RAID 5 successively, one data block to one disk, then the next data block to the next disk, and a parity block to the third disk. We can represent an example of such a scheme in the following table ...

First RAID disk	Second RAID disk	Third RAID disk
PD	1	2
3	PD	4
5	6	PD

... where the numbers represent the order in which the data blocks are written to their respective disks, and PD stands for the "parity of data" block.
(This table represents only an example, and the block order may be arbitrary in a general case.)

Here that means that the file record numbers in MFT will increase by one within one data block. Then the MFT will continue on another disk, where file record numbers will increase by one within its respective data block, the third disk containing the parity block. And so on.

So, to find the block size, we will look at the file record numbers on this disk to discover the place where they no longer increase by one. This place would mean the end of that data block. Then we will look at other disks to find the disk and the place on it where file record numbers in the MFT resume increasing by one. Then we will look at another disk to find where the MFT continues, and so on.

Such a search can be done by scrolling down the text in the Editor by two sectors.

On Disk 3 the data block ends in sector 3,153,919 with file record number 3F 00.


Click image to enlarge
Last file record in Disk3. End of a data block is on the next sector (3,153,919).

Looking at other disks, we find that this MFT continues on Disk 1 in sector 3,153,792 with file record number 40 00 and ends in Sec: 3,153,919 with file record number 7F 00. And so on.


Click image to enlarge
File record continues in Disk1. Start of a data block.


Click image to enlarge
Last file record in Disk1. End of the data block is on the next sector (3,153,919)

The final results are represented in the Table below:

Disk1	Disk2	Disk3
Sec: 3,153,792 Rec: 40 00 Sec: 3,153,918 Rec: 7F 00 Sec: 3,153,919 End of stripe	Sec: 3,153,792 No records Sec: 3,153,918 No records Sec: 3,153,919: End of stripe	Sec: 3,153,792 Rec: 00 00 Sec: 3,153,918 Rec: 3F 00 Sec: 3,153,919 End of stripe
Sec: 3,153,920 Rec: No records Sec: 3,154,046 Rec: No records Sec: 3,154,047 End of stripe	Sec: 3,153,920 Rec: C0 00 Sec: Sec: 3,154,046 Rec: FF 00 Sec: 3,154,047 End of stripe	Sec: 3,153,920 Rec: 80 00 Sec: 3,154,046 Rec: BF 00 Sec: 3,154,047 End of stripe
Sec: 3,154,048 Rec: 00 01 Sec: 3,154,174 Rec: 3F 01 Sec: 3,154,175 End of stripe	Sec: 3,154,048 Rec: 40 01 Sec: Sec: 3,154,174 Rec: 7F 01 Sec: 3,154,175 End of stripe	Sec: 3,154,048 Rec: No records Sec: 3,154,174 Rec: No records Sec: 3,154,175 End of stripe

No records mean this is a parity block.


Click image to enlarge
Example of a parity sector

Looking at the table above, we can find the following parameters:

Disk order:
First RAID disk Disk3.arc
Second RAID disk Disk1.arc
Third RAID disk Disk2.arc

Offset: 0
Stripe size: 128 sectors, or 65,536KB (64KB)
Stripe order: (PD stands for Parity of Data)

First RAID disk	Second RAID disk	Third RAID disk
1	2	PD
3	PD	4
PD	5	6

Now we can create such a RAID in R-Studio:

Click image to enlarge
RAID 5 object created in R-Studio

R-Studio finds a valid file system on the RAID (Partition 1)

Double-click Partition 1 to enumerate its files:

Click image to enlarge
Folder/File structure found by R-Studio

R-Studio shows a valid folder/file structure, which is a good symptom. To finally verify that we created the RAID with the correct parameters, you can preview a file. A file for the preview should be larger than the block size * (Number of disks -1). 128KB for our case.

Click image to enlarge
Preview of file Picture 236.jpg

The file is previewed successfully. We have created a RAID with correct parameters.