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.
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.
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.
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
click here for more information
Please email comments and corrections.