4 Replies Latest reply: Jul 17, 2012 6:31 PM by Claudio Sanchez1
Trey Level 5 Level 5 (4,225 points)

Ok, let me preface this by saying that I've never used Xsan, so I'm not sure if I'm using the terminology correctly. Feel free to correct me or point me in the right direction so that I may provide better clarification.


I've got a new client who has  about 5 tb of data locked up in a Netgear ReadyNAS that was set up as an Xsan device on a Mac Pro Server running Lion Server 10.7.4. This was set up by a previous IT services company, and we were preparing to move all of their data to a regular RAID NAS device (there is no use for an Xsan in this office environment) and initiate backup solutions. However, several days ago, the server's boot volume crashed fatally and could not be recovered. There was no backup of the boot volume, so we had to start again from scratch. Since reinstalling Lion Server on the Mac Pro, we have been unable to retrieve the data off of the Netgear ReadyNAS.


There is no backup of the data on the drive, so we're treating this with kid-golves as far as our approach. So far we've tired connectng to the NAS, but are only seeing a couple of shares that don't appear to hold any data. We've been on the phone with Apple's Enterprise Support Group, and been escalated up to the point of having to pay for higher-end supporty. At that point, we phoned Netgear Support to see what they could offer. They're kindly looking into it over the weekend by logging in remotely, but I'm here to ask if there's anyone here who might have experience with a smilar siuation.


I've been really hesitant to try and connect to the drive with Xsan Admin, as I want to ensure that nothing gets deleted. Does anyone have a suggestion as to something we might try to get at this data? It seems like it would be a simple matter of connecting to the drive, but that's proving to not be the case.

  • Strontium90 Level 4 Level 4 (3,700 points)

    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.

  • Trey Level 5 Level 5 (4,225 points)

    Your assessment is pretty much spot-on. I've already spoken to a forensic data recovery speicialist, and he feels like he can get the data off as long as it's not encrypted. Does Xsan by its nature encrypt the data?

  • Strontium90 Level 4 Level 4 (3,700 points)

    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.

  • Claudio Sanchez1 Level 1 Level 1 (65 points)

    If the only problem is a missing configuration file, it might be possible to create a new volume configuration file that will allow you to start and mount the volume again. Check with AppleCare or someone who has recovered data from Xsan before.