(Why they did not do Direct attached solution I am still wondering). This is a good thing as you may have as few as one LUN, but likely three. If you don't have the volume info (/Library/FileSystems/Xsan/config) this is like guessing a number in an infinite set. The challenge will be in stitching the data together across the LUNs. Otherwise, bite the bullet and get that drive out to a data recovery service and pray. If there are more details or the conditions are better than you describe, reply. If the Xsan config files were present you could, in theory, stitch together a new controller and resurrect that volume.Īnd finally, you do not describe a backup solution for the San volume. ![]() With the loss of the boot volume, these files are now not available. Next, the files that you REALLY need, /Library/FileSystems/Xsan/*, were never backed up. With some luck they can recover enough of the drive to allow you to sticth this together. 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). The failure of that platter means the failure of everything. Based on this description, it sounds like the boot volume was not a mirror boot so all data was on one platter. Next, you mention the boot volume failed with no backup. Are there SAN clients in this scendario or was there just the controller and folders reshared over file services? Without it, you have no replication of the volume config information. Deploying an Xsan with a single controller is foolish at best, negligent at worst. This is mistake number 1 of whoever set this solution up. 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.įirst, you do not describe the presence of a meta data backup. You should track down the solution provider and choke them. 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. I've been really hesitant to try and connect to the drive with Xsan Admin, as I want to ensure that nothing gets deleted. 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. At that point, we phoned Netgear Support to see what they could offer. ![]() 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. 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. There is no backup of the data on the drive, so we're treating this with kid-golves as far as our approach. Since reinstalling Lion Server on the Mac Pro, we have been unable to retrieve the data off of the Netgear ReadyNAS. There was no backup of the boot volume, so we had to start again from scratch. However, several days ago, the server's boot volume crashed fatally and could not be recovered. 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. 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. Feel free to correct me or point me in the right direction so that I may provide better clarification. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |