I read this and began to shake. You should track down the solution provider and choke them.
I hate to be the one to tell you, but based on your post, the data is likely lost forever and this is for many reasons.
First, you do not describe the presence of a meta data backup. This is mistake number 1 of whoever set this solution up. Deploying an Xsan with a single controller is foolish at best, negligent at worst. Without it, you have no replication of the volume config information. Are there SAN clients in this scendario or was there just the controller and folders reshared over file services?
Next, you mention the boot volume failed with no backup. Based on this description, it sounds like the boot volume was not a mirror boot so all data was on one platter. The failure of that platter means the failure of everything. Your only recourse here is to send the drive out to a drive recovery service or attempt a controller board swap (fingers crossed it is just the controller that failed). With some luck they can recover enough of the drive to allow you to sticth this together. This is mistake number 2.
Next, the files that you REALLY need, /Library/FileSystems/Xsan/*, were never backed up. With the loss of the boot volume, these files are now not available. If the Xsan config files were present you could, in theory, stitch together a new controller and resurrect that volume.
And finally, you do not describe a backup solution for the San volume. Cry....
I am sorry for your loss. If there are more details or the conditions are better than you describe, reply. Otherwise, bite the bullet and get that drive out to a data recovery service and pray.
No. There is no encryption.
The challenge will be in stitching the data together across the LUNs. If you don't have the volume info (/Library/FileSystems/Xsan/config) this is like guessing a number in an infinite set. Now, you mention a single RAID chassis. This is a good thing as you may have as few as one LUN, but likely three. (Why they did not do Direct attached solution I am still wondering). The ReadyNAS may have one MetaData LUN which may be small and then one or two other Data LUNs. Now it is possible that they mixed Metadata and Data on one LUN (which negates to entire reason for Xsan...), in which case, this may be easier to recover from.
If this was my cross to bear, I would focus on the boot volume and leave the SAN volumes untouched. If you can get the SAN configuration files you might be able to resurrect the drive enought to extract data.
The reality is that the data is sitting on the ReadyNAS as you have smartly not done anything to the volume. The challenge is that you have no map telling you the structure. Thus there is no way to tell where a file starts, stops, or is fragmented across blocks.
Good luck. I am sorry this is your first experience with Xsan.