Modifying StorView configuration binary file

I did not backup the configuration after two disks were replaced in a logical drive.
So, when the Xyratex F5404E lost its configuration (long story),  the previous binary configuration file did not know about the two newer disks.
It was looking for the previous two disks (based on serial number).

Had I backed up after replacing the two disks, I would not have this problem. The SES would know that it should use the two newer disks as part of the logical drive/RAID.

I thought that I could replace the two old serial numbers in the binary file, put in the new serial numbers and then re-upload it to the SES (StorView) of the F5404E.
This did not work.
I received the following error message:
"(05/26/00) Invalid field found in parameter list. Return to main screen and retry operation."

I don't know what else might need to be changed in the binary file. I used a Hex editor to edit the binary file and change the two serial numbers. I hoped that it would be enough. Since I don't know the format of the binary file, I am obviously stuck. I have no way to tell it that the logical drive/RAID will work fine if it uses the newer disks which have existing data on them.
Who is Participating?
DavidConnect With a Mentor PresidentCommented:
I wrote two of the RAID configurators when I worked at Xyratex years ago. I can tell you with absolute certainty that the layout is vendor specific and there  is much more to it than cloning the serial numbers.

The layout is only available under NDA, so you have to talk to Xyratex to get it.  Unless you are an OEM developer, then you probably have zero chance of getting it, so just be prepared for this contingency.

In grand scheme of things, just come to terms that the data is lost and the only way to get it back is to spend several thousand dollars minimum (could be well over $20K on a large config)  I doubt Xyratex even does this any more.  

So write it off as 100% data loss  unless you can afford recovery.
DavidConnect With a Mentor PresidentCommented:
.. Besides, even if you paid somebody to do this (I am not interested, BTW), then you still have grave risk of data loss because the config file contains data relating to the state of the HDDs. There is also metadata hidden from the config files that deal with whether or not a transition or resilvering was occurring.  You would have lost that.

Even if you are absolutely certain that nothing changed, then any recovery expert wouldn't even consider this task w/o doing bit-level cloning of all disks for safety, which contributes to the expense and resources required for recovery.
londonsysadminAuthor Commented:
Although I'm disappointed, receiving a rapid and useful response from an insider is appreciated.
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

There is a possible plan "B" depending on the number of drives and known configuration. Example if you only had 8 drives configured as a single RAID6 that occupied 100% of the disks, then brute force recovery on cloned drives would provide a means to get data back using one of the enclosures as a JBOD expansion unit and some software.

So exactly what was the configuration?  # of disks, raid levels, partitioning, topology, etc ... maybe it won't be bad to manually build from scratch on temp drives.
londonsysadminAuthor Commented:
Thanks! So, the situation is like this:

48 disk total. All identical sizes (mostly same model and vendor)
3 global spares
Three 15 disk RAID5, therefore 3 logical drives
The file system is Quantum's StorNext.
The StorNext metadata is kept on another unit, not this one
There are four F5404E's for a single StorNext file system instance.
There are four StorNext stripe-groups and each stripe group comprises 3 logical drives

The above scenario complicates things horribly. StorNext is a closed file system and inner details are not available.
I've successfully done much worse, but the nature of your configuration would take 3-4 days, perhaps longer,  and require physical possession of the kit, plus 48 scratch drives of same capacity.

The StorNext file system isn't a big problem, but does eliminate some short cuts.   The bad news is you won't find anything off the shelf that could assist you.  (Which would have been an option on a much smaller config, and I was hoping to be able to tell you how to do it with something that is off the shelf). could probably get it back, but be prepared for something in the $50K range.  Frankly, they are the only people I would trust other than one of the few developers out there that have left the company.  

All Courses

From novice to tech pro — start learning today.