If vxdg import is used with -C (clears locks) and/or -f (forces import) to import a disk group that is still in use from another host, disk group configuration corruption is likely to occur. Volume content corruption is also likely if a file system or database is started on the imported volumes before the other host crashes or shuts down.
If this kind of corruption occurs, your configuration must typically be rebuilt from scratch and all data be restored from a backup. There are typically numerous configuration copies for each disk group, but corruption nearly always affects all configuration copies, so redundancy does not help in this case.
As long as the configuration backup daemon, vxconfigbackupd, is running, VxVM will backup configurations whenever the configuration is changed. By default, backups are stored in /etc/vx/cbr/bk. You may also manually backup the configuration using the vxconfigbackup utility. The configuration can be rebuilt using the vxconfigrestore utility.
See the vxconfigbackup, vxconfigbackupd, vxconfigrestore man pages.
VxVM vxconfigd ERROR V-5-1-569 Disk group group,Disk disk: Cannot auto-import group: reason
Association not resolved Association count is incorrect Duplicate record in configuration Configuration records are inconsistent
Disk group has no valid configuration copies
If you use the Veritas Cluster Server product, all disk group failover issues can be managed correctly. VCS includes a high availability monitor and includes failover scripts for VxVM, VxFS, and for several popular databases.
The -t option to vxdg prevents automatic re-imports on reboot and is necessary when used with a host monitor (such as VCS) that controls imports itself, rather than relying on automatic imports by Veritas Volume Manager.
See the Veritas Storage Foundation and High Availability Solutions Troubleshooting Guide.