Anyone who uses AppleRAID will know how often it declares that a perfectly healthy disk is no longer a valid member of a Raid set. What you may not have experienced is when it wont rebuild. For a stripped set, the practical only solution is a backup. For a mirror there are some things you can do. Typically when diskutil or the GUI wont repair the low level AppleRAID.kext wont load, or will load and fails reporting it cant get a controller object. In the logs you might also see the Raid set is degraded or just offline. If its really bad DiskUtility and diskutil will hang somewhere in the kernel, and you wont be able to get a clean reboot.
Here is one way to fix:
Unplug the disk subsystem causing the problem.
Reboot, you may have to pull the plug to get shutdown.
Once up, move the AppleRAID.kext into a safe place eg
mkdir ~/kext sudo mv /System/Library/Extensions/AppleRAID.kext ~/kext
Watch the logs to see that kextcache has rebuilt the cache of kernel extensions. You should see something like
30/09/2014 13:21:37.518 com.apple.kextcache: /: helper partitions appear up to date.
When you see that you know that if you plugin the RAID Subsystem the kernel wont be able to load the AppleRAID.kext and so you will be able to manipulate the disks.
Plugin the raid subsystem and check that it didnt load the kernel extension,
kextstat | grep AppleRAID
You will now be able to do diskutil list and you should see your disks listed as Apple RAID disks, eg
$ diskutil list ... /dev/disk2 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *750.2 GB disk2 1: EFI 209.7 MB disk2s1 2: Apple_RAID 749.8 GB disk2s2 3: Apple_Boot Boot OS X 134.2 MB disk2s3
/dev/disk3 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *750.2 GB disk3 1: EFI 209.7 MB disk3s1 2: Apple_RAID 749.8 GB disk3s2 3: Apple_Boot Boot OS X 134.2 MB disk3s3
At this point the disks are just plain disks. The AppleRAID kernel extension isn’t managing the disks. Verify with
$ diskutil appleRAID list No AppleRAID sets found $
Since you cant use them as RAID any more, and so cant use the diskutil appleRAID delete command convert the RAID set into normal disks you have to trick OSX into mounting the disks. To do this you need to edit the partition table, without touching the data on the disk. You can do this with gpt
$ sudo gpt show disk2 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 1464471472 2 GPT part - 52414944-0000-11AA-AA11-00306543ECAC 1464881112 262144 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC 1465143256 7 1465143263 32 Sec GPT table 1465143295 1 Sec GPT header $ sudo gpt show disk3 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 1464471472 2 GPT part - 52414944-0000-11AA-AA11-00306543ECAC 1464881112 262144 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC 1465143256 7 1465143263 32 Sec GPT table 1465143295 1 Sec GPT header $
According to https://developer.apple.com/library/mac/technotes/tn2166/_index.html the partition in index 2 with a partition type of 52414944-0000-11AA-AA11-00306543ECAC is a Apple_RAID partition. Its actually HFS+ with some other settings. Those settings get removed when converting it form RAID to non RAID, but to get it mounted we can just change the partition type. First delete the entry from the partion table, then recreated it with the HFS+ type exactly the same size.
$ gpt remove -i 2 disk2 disk2s2 removed $ gpt add -b 409640 -s 1464471472 -t 48465300-0000-11AA-AA11-00306543ECAC disk3 disk2s2 added
OSX will mount the disk. It will probably tell you that its been mounted read only, and cant be repaired. At the point you need to copy all the data off onto a clean disk, using rsync.
Once that is done you can do the same with the second disk and compare the differences between both your RAID members. When you have all the data back, you can consider if you leave the AppleRAID.kext disabled or use it again. I know what I will be doing.