There are at least four ways to generate disaster recovery information for your storage products. Each has its own set of advantages and disadvantages. I attempt to compare/contrast the advantages/disadvantages below of the first three below. I have not tested the fourth yet.


The first method is to follow the advice in Sun InfoDoc #12006. It falls short for some people in several ways, but it is a good starting point and is exactly what some people need, and provides a good recovery methodology and checklist. I have replicated it here for those that do not have contract services but do have an array running Volume Manager. (disaster recovery of Solstice DiskSuite can be done off normal tape backup because of the way the info is kept on the local host vs. the array)

The shortcomings of this are that it uses vxmake -d to recover your configuration following a vxprint. This will work very well if you have a new array that is exactly the same disk-for-disk as the old one. However, if you are like us, you may not have money to have a spare array hanging around unused in some vault locked deep inside a mountain. ;) So, if a disaster happens, you have to buy whatever is currently available, which means that the disk sizes will probably be different, the cylinder alignment assumptions that VxVM originally made will probably be invalid, and the layout on these disks may result in something non-optimal for you. The advantages are, of course, that if you do have a configuration exactly the same as the old one, you can use this to recreate your setup exactly as it was.

vxreconstruct & vxunrelocate

The vxunrelocate and The vxreconstruct scripts were written by Mike Arnott, a Sun FE in Australia. They area written in Bourne shell. The main purpose is to use vxprint information to move subdisks back to their original location after a disk failure and subsequent hot relocation by VxVM. So, they can provide greater recovery flexibility in getting your array back than a normal vxmake. They can be used for partial and complete recovery of volumes. However, they also have the same 'you get exactly what you had' feature, which may not be what you want.


vxrecreate was written by Doug Hughes at Auburn University (me) as a short Perl script to recreate volumes. It too uses vxprint to get the information off of the arrays, but it does not recreate the volumes exactly. Instead, it gets the approximate size of the volume (rounding up to the nearest 250MB boundary) and then uses vxassist to create the volume given the layout and striping parameters associated with the original. So, if you had a 6 disk RAID-5 stripe, you get a 6 disk RAID-5 stripe of approximately the same size, but which disks it picks are picked based on what vxvm thinks is appropriate, and they will be aligned how vxvm thinks is appropriate as well. The 250MB rounding factor can be tuned at the top of the script by setting the RF variable.

  1. We don't have any mirrored or striped and mirrored volumes, but I created a test pair (with and without log), and the script seemed to recreate them adequately, so I'm satisfied. Anybody finding discrepancies can modify and get results back to me and I'll keep a central distribution copy.
  2. It uses the default logsize when creating a volume. If you have increased your log sizes (which, by the way, probably isn't at all necessary) from the default, you need to modify the script
  3. I don't care about what disks the new filesystems end up on. I have specified the nospan and contig options for vxassist to recreate the volume so that it does not span multiple disks. If you have volumes whose plex components span multiple physical disks, you will need to remove nospan.
  4. It makes no effort to attempt to put disks or subdisks back in their original places because, as I figure it, if we have a tornado flatten this place, I doubt we'll be able to exactly replicate it down to the disk anyway (finding 2GB disks might be tough in the near future)
  5. I've only tested this on an ssa - sena people that want to try it, check it out and report discrepancies please.

None of the above will create the file system on the volume for you. You need to do that for yourself. The below one will, though.

A Solaris cron package by Espen Martinsen

Here is a simple solaris-package, that will tell cron to dump the entire config every nigth, and store it under /usr/vx, rotating in 7 generations. It is followed by scripts that is used to rebuild it, and also a few scripts that will help you move volumes between diskgroups.
click here for more information

Please email comments and corrections.