Symptom: 

How to backup VERITAS Volume Manager (VxVM) configuration for a disk group and use the backup to recover the disk group configuration  


Solution: 

The following are instructions on how to backup VxVM configuration information from the private region of all VxVM disks and other relevant information to recover after misconfiguration or failure. This is also good to do for future reference in case of failure.

Save the outputs of the following commands in separate files (which could be retrieved later):

1.  # vxdisk list     (this contains the mapping between da (e.g., c0t0d0) and dm (e.g., disk01) records)
2.  # vxdisk -q list | awk '{print $1}' | xargs vxdisk list     (this contains detailed info for each disk)
3.  # vxdisk -q list | awk '{if ($2 != "simple") print "/dev/rdsk/"$1}' | xargs prtvtoc     (this contains the VTOC info for each disk) 

Also do so for each disk group. If the version of the VxVM package is 3.x or later then apply step 4b only, otherwise apply 4a only:

4a. # vxprint -g disk_group_name -hmvps   (this contains detailed info for all the volume, plex, and subdisk objects for the specified disk group)
4b. # vxprint -g disk_group_name -rhmvps  (this contains detailed info for all the volume, sub volume, plex, and subdisk objects for the specified disk group)

It will be ideal if the above output is backed up every time after a configurational change (please see the explanation at the end of this TechNote). What is not a good idea is to set up a cron job to back them up often.

For example, (if it is VxVM 2.x):

# vxdisk list > vxdisk_list
# vxdisk -q list | awk '{print $1}' | xargs vxdisk list > vxdisk_list_detail
# vxdisk -q list | awk '{if ($2 != "simple") print "/dev/rdsk/"$1}' | xargs prtvtoc > prtvtoc_all_disk
# vxprint -g datadg -hmvps > vxprint_datadg_config

For example, (if it is VxVM 3.x):

# vxdisk list > vxdisk_list
# vxdisk -q list | awk '{print $1}' | xargs vxdisk list > vxdisk_list_detail
# vxdisk -q list | awk '{if ($2 != "simple") print "/dev/rdsk/"$1}' | xargs prtvtoc > prtvtoc_all_disk
# vxprint -g datadg -rhmvps > vxprint_datadg_config

In the event of a non-rootdg disk group configuration failure or error (such as failure to import a disk group by all means) that requires a rebuild of the entire configuration database for the disk group, these outputs can be used to recreate the disk groups (note that step 1 is not necessary if the desired disk group is importable.)

1.  Re-initialize (or recreate) the disk group exactly according to the vxdisk list output, i.e., make sure that the mapping between the device names (disk access names (da names)) and the logical names (disk media names (dm names)) is exactly the same as the one in the vxdisk list output:

# vxdg init disk_group_name  dm_name_1=da_name_1  dm_name_2=da_name_2  ...

For example,

# vxdg init datadg d1=c1t1d1 d2=c1t1d2 ...

For a disk group with a large number of disks, use:

# vxdg init datadg `awk '{if ($4 == "datadg") print $3"="$1}' vxdisk_list`

Extreme caution should be taken for this step for various reasons. For instance, if two da names are swapped (e.g., c1t1d1 and c1t1d2), mapping between the da names and dm names according to the not-yet-updated vxdisk list output will lead to a potential disaster. At this point, the detailed vxdisk list could help if the private regions of the disks have not been removed or damaged. The disk ID can be obtained from the on-disk private region for each disk (e.g., vxdisk list c1t1d1 and c1t1d2, and so on) and then can be compared with that from the saved detailed vxdisk list output,  hence, a recovery of the correct mapping. 

If this step does not succeed or there are some doubts at this point, please call Customer Support immediately since it may require initializing disks, which would require careful examination of the other outputs that have been backed up (i.e., the detailed vxdisk list and the VTOC info) and the particular nature of the situation.

2.  If step 1 is successful, then execute the <vxmake> command using the vxprint output: 

# <vxmake> -g disk_group_name -d config_file_name

For example,

# <vxmake> -g datadg -d vxprint_datadg_config

This should restore the original configuration for the disk group.

3. If step 2 completes successfully, then start all the volumes with vxvol -g disk_group_name startall or one by one with vxvol -g disk_group_name start volume_name. Now it is time to verify the data on the volume. If there is a file system on the volume then check the file systemn using fsck or mount the file system. If there is no file system on the volume then use appropriate ways to verify the data.

Configurational changes refer to any changes that alter the state or attribute of the volume manager objects, which includes the disk group, disk, volume, plex, subdisk, etc. (For example, add or remove a disk to and from a disk group, attach or detach or disassociate a plex, shrink or grow a volume, and many more things.)