Recovering UFS RAID 5

[wiebsomean]

I'm having a lot of trouble finding the correct RAID5 settings to
recover my UFS formatted array which normally works under a FreeBSD
distro.

I'm using the Mac version of R-Studio (network) and have booted my
sick machine from the linux recovery ISO. Incidently, connecting to
the machine was no problem after i got the correct subnet settings
sorted.

The RAID was managed the ICH9R chipset with a 64KB block size ( I
believe), and died after something went pop with one of my 3x400GB
disks. The BIOS states that the array is Damaged, but despite the fact
only one disk is damaged, the OS won't boot even though it resides on
a completely separate physical disk, so i turned to R-Studio.
Incidentally, the dead disk shows up in R-Studio, but has no partition
info at all. The other two both show up, and have a single partition
in the devices window (left hand side of the GUI), and I believe all,
or nearly all of their data is intact. I've thus decided to use a
missing disk in the Virtual RAID Block.

I am clearly a numpty as at the start of this problem I took each of
the disks out and checked cabling was secure, and took no notice of
the correct SATA port order. One disk shows a GPTPart0 with a 17KB
Partition offset in the devices view, the other a Partition 1 with a
34KB Partition offset, and the third nothing at all. I suspect that
GPTPart0 = Disk 1 and Partition1 = Disk 2, but I could have this
totally messed up.

Whenever I change RAID settings I don't get any magic self detecting
Partition appearing under my Virtual RAID Block as referred to in the
user guide, and I've been running scans of the first 5GB to determine
whether I'm likely to succeed in data recovery. When i do this I get
dozens, or hundreds of 'Partitions' showing up in the scan results,
with sizes varying from a few MB upto the expected 745.22GB. Opening
the files from these sometimes suggests a valid filename, but i cannot
recover a file that my Mac can open at all.

Anyway, I've been at this for two weeks now, and turn to the forum for
guidance, as i'm clearly shooting in the dark. Your document on
Finding_RAID_parameters is helpful, but I'm unsure what I should be
looking for in a UFS formatted RAID. Does such a 'disk' have an MBR?
What doe the hex signature look like for this part of the disk? How
can i determine the correct offsets, and will they be the same for
each disk? Is the NTSC example valid for a UFS disk?

Your response is truly appreciated. If I don't get the pictures of my
baby girl back, my wife will kill me. Yes I had a back up, and I don't
want to talk about the fact that that got mysteriously corrupted some
weeks before this sorry saga started.

[wiebsomean]

An update on my progress which may prove illuminating/instructive to others:

Since i don't know pretty much anything about my original RAID, i've been testing around a number of parameters to see what gives the best success rate.

The parameters are:

Block Size - 32KB, 64KB, 128KB - I tried one at 16KB - but this returned almost no usable files, so i'm pretty sure that's not it at this stage.

Offset of my two remaining disks - I'm using the offset in sectors where the two disks actually start writing data. In my case disk 0 (i.e. the one with GPT-0 on it) has 33 null sectors, and sector 34 is the first containing any actual data) Disk 1 (i.e. the one with Partition 1 on it) starts at sector 63. I used the hex editor built into R-Studio for this analysis per the instructions on 'finding RAID params' referred to in the original post.

Synchronisation - I've tried all 4 options for each of the block sizes above.

Disk Order - This is my biggest unknown, but using the hex editor and some nuggets of info on the wikipedia page for GUID Partition Tables (http://en.wikipedia.org/wiki/GUID_Partition_Table), i went looking at the final sector on my disks, and on GPT0 I found what looks like a copy of the Partition Table Header. This named my 3 disks in the order GPT-0, Missing, Parition 1 - My shorthand for this disk arrangement became 0-M-1. I have assumed that this was the original order of the disks in my RAID, although i've tested some of my other parameters using alternative arrangements, mostly 0-1-M and on one occasion M-0-1.

With all these permutations and combinations, I then set about scanning the first 5GB of each RAID config, and then recovering JPEG files returned in the Extra Found FIles listing at just under 16KB, 32KB, 64KB, 128KB and >128KB. I found that JPEG files can be opened by my Mac's Preview app, even if a lot of data is missing. This gave me the opportunity of not only saying 'bingo' i can open a 15.5KB file, but I can also open 60% of 63KB file, for example, with a given RAID configuration.

This process is ongoing, and has so far has taken the better part of two weeks, with me managing 3 or 4 RAID configs per day as I only have a couple of hours each evening to devote to the task.

I'm sure there's a way to analyse the hex of individual sectors and do this more scientifically, but I can't find a good description of the UFS equivalent of NTFS metafiles (http://en.wikipedia.org/wiki/NTFS#Metafiles), so looking at the raw hex didn't prove highly illuminating. That said, i have figured out that the string FIFO denotes the beginning of a file in UFS, much as "EB 52 90 4E 54 46 53 20 20 20 20" denotes the beginning of the NTFS boot sector.

Anyway, if anyone can help me with a technical description of what raw file data looks like on UFS, i'll be very grateful. And if not, I hope my experiences in trial and error data recovery help speed you to your solution.

I'll finish on a positive note by saying I have managed to recover some good files so far, but the largest has only been 54KB - and yes I have paid the license fee, so I don' think that's the problem. I know R-Studio will get me there. Persistence will prevail...

[Alt]

That's true, it's hard to find information about the UFS file system, that's why none answered.
But I can give you one advice - you may preview jpg files simply by clicking them, without saving them to the disk. You can preview files of any size regardless of whether R-Studio is in its demo mode or properly registered.