Backup and Recover VxVM Disk Configuration

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.

Backup VxVM Configuration

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

  1. # vxdisk list
    — This contains the mappings between da (i.e: c0t0d0) and dm (i.e: 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.
  4. Also for each disk group, perform:
    1. For VxVM 2.x
      vxprint -g <disk_group_name> -hmvps
      — This contains detailed info for all the volume, plex, and subdisk objects for the specified disk group. For example:
      # vxprint -g datadg -hmvps
    2. For VxVM 3.x or later
      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. For example:
      # vxprint -g datadg -rhmvps

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 article). What is not a good idea is to set up a cron job to back them up often.

Recover VxVM Configuration

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.

    Caution: If this step does not succeed or there are some doubts at this point, please call your 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:
    • Start all the volumes with:
      vxvol -g <disk_group_name> startall
      or one by one with:
      vxvol -g <disk_group_name> start <volume_name>
    • 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.

Definition of Configurational changes

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....