Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Need help recovering data from an Xsan volume

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.

Posted on Jul 14, 2012 12:42 PM

Reply
Question marked as Best reply

Posted on Jul 16, 2012 5:32 AM

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.

4 replies
Question marked as Best reply

Jul 16, 2012 5:32 AM in response to Trey

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.

Jul 16, 2012 7:25 AM in response to Trey

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.

Need help recovering data from an Xsan volume

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.