Restoring a Disk Group Configuration

You can use the vxconfigrestore utility to restore or recreate a disk group from its configuration backup. The restoration process has two stages: precommit and commit. In the precommit stage, you can examine the configuration of the disk group that would be restored from the backup. The actual disk group configuration is not permanently restored until you choose to commit the changes.

You can choose whether or not any corrupted disk headers are to be reinstalled at this stage. If any of the disks' private region headers are invalid, restoration may not be possible without reinstalling the headers for the affected disks.

The following command performs a precommit analysis of the state of the disk group configuration, and reinstalls the disk headers where these have become corrupted:

The disk group can be specified either by name or by ID.

The -l option allows you to specify a directory for the location of the backup configuration files other than the default location, /etc/vx/cbr/bk. See Backing Up a Disk Group Configuration for details.

To specify that the disk headers are not to be reinstalled, use this form of the command:

At the precommit stage, you can use the vxprint command to examine the configuration that the restored disk group will have. You can choose to proceed to commit the changes and restore the disk group configuration. Alternatively, you can cancel the restoration before any permanent changes have been made.

To abandon restoration at the precommit stage, use this command:

To commit the changes that are required to restore the disk group configuration, use the following command:

If no disk headers are reinstalled, the configuration copies in the disks' private regions are updated from the latest binary copy of the configuration that was saved for the disk group.

If any of the disk headers are reinstalled, a saved copy of the disks' attributes is used to recreate their private and public regions. These disks are also assigned new disk IDs. The VxVM objects within the disk group are then recreated using the backup configuration records for the disk group. This process also has the effect of creating new configuration copies in the disk group.

Volumes are synchronized in the background. For large volume configurations, it may take some time to perform the synchronization. You can use the vxtask -l list command to monitor the progress of this operation.

For more information, see the vxconfigrestore(1M) manual page.

Resolving Conflicting Backups for a Disk Group

In some circumstances where disks have been replaced on a system, there may exist several conflicting backups for a disk group. In this case, you see a message similar to the following from the vxconfigrestore command:

The solution is to specify the disk group by its ID rather than by its name to perform the restoration. The backup file, /etc/vx/cbr/bk/diskgroup. dgid/ dgid.dginfo, contains a timestamp that records when the backup was taken.

The following is a sample extract from such a backup file that shows the timestamp and disk group ID information:

Use the timestamp information to decide which backup contains the relevant information, and use the vxconfigrestore command to restore the configuration by specifying the disk group ID instead of the disk group name.