Problem
If using vxconfigrestore is not possible, another method for recovering the disks is to compare the attributes of the disks with the records that are contained with the private region configuration database.
Error Message
Disk group has no valid configuration copies
Solution
| This article is a part of a set on troubleshooting failed, or failing, disks. Click here to start at the beginning: https://www.veritas.com/docs/000080622 |
Table of Contents
Introduction
Matching disks using UDIDs
Matching disks using Disk IDs
Reinitializing the disk while preserving existing data
Adding the disk back to the diskgroup with vxdg
Introduction
(Back to top)
If using vxconfigrestore is not possible, another method for recovering the disks is to compare the attributes of the disks with the records that are contained with the private region configuration database. In most cases, matching these disk attributes with records that are contained within the private region configuration database confirms whether or not the disk shown in vxdisk list (under the "DEVICES" column) is really the same disk that is reported in the "failed was" record.
Matching disks using UDIDs
(Back to top)
Using UDIDs is usually preferred over using Disk IDs because the Disk ID is contained within the Veritas private region and it may change if a disk is reinitialized, while the UDID remains the same.
Match the UDID that is recorded in the private region configuration database with the UDID that is found within the disk headers of any disks that need to be added back into the disk group. In most cases, a match confirms that the disk shown in vxdisk list (under the "DEVICES" column) is really the same disk that is reported in the "failed was" record.
1. Use vxdisk list to find the UDID from the disk header of a disk that needs to be added back into the disk group (Figure 1).
Figure 1 - Using vxdisk and grep to find the UDID for a disk in the disk header
|
Syntax:
vxdisk -o alldgs list vxdisk list <device_name> Example, with typical output: # vxdisk -o alldgs list
|
2. Determine if there is a record of this UDID in the backup copy of the private region configuration database (Figure 2).
By default, Volume Manager stores automatic backups of the private region configuration database to /etc/vx/cbr/bk/<disk_group>/*.diskinfo. If a backup was taken manually, using with vxconfigbackup or privutil, the UDID may also be found there. If the UDID is found, note the value of the "Device" record to which it is associated. If this matches the UDID found in Step 1, then the disks are probably the same.
Example, with typical output: # less /etc/vx/cbr/bk/datadg.1336573086.38.Server101/1336573086.38.Server101.diskinfo(excerpt from output) Device: disk_4 |
If no copies of the private region configuration database are available, disk.info may be used as an alternative (Figure 3). Disk.info only exists if disk persistence is enabled in dmppolicy.info. By default, both of these files are found under /etc/vx.
Figure 3 - Searching for the UDID record within disk.info
# cat /etc/vx/disk.info |
Matching disks using disk IDs
(Back to top)
It is also possible to match disks using Disk IDs. However, because the Disk ID is contained within the Veritas private region, it may change if a disk has been reinitialized, while the UDID will remain the same. For this reason, do not attempt to use Disk IDs to match disks if a disk has already been reinitialized, such as with vxdisksetup or vxdisk init. When a disk is reinitialized, the existing private region is replaced. This results in a new Disk ID that is different from the original.
1. Use vxdisk list to find the Disk ID from the disk header of a disk that needs to be added back into the disk group (Figure 4).
Figure 4 - Using vxdisk to find the Disk ID in the header of a disk
Syntax: vxdisk -o alldgs list vxdisk list <device_name> Example, with typical output: # vxdisk -o alldgs list# vxdisk list disk_4 | grep -i disk: |
2. Determine if there is a record of this Disk ID in the backup copy of the private region configuration database (Figure 5).
By default, Veritas stores automatic backups of the private region configuration database to /etc/vx/cbr/bk/<disk_group>/*.diskinfo. If a backup was taken manually, using with vxconfigbackup or privutil, the UDID may also be found there.
If the Disk ID is found, note the value of the "Device" record to which it is associated. If this matches the UDID found in Step 1, then the disks are probably the same.
Figure 5 - Finding the Disk ID within the backup of an enabled copy of the configuration database
Example, with typical output:
# less /etc/vx/cbr/bk/datadg.1336573086.38.Server101/1336573086.38.Server101.diskinfo
(excerpt from output) Device: disk_4
|
Reinitializing the disk while preserving existing data
(Back to top)
Determine the offset and length of the public region. Then, reinitialize the disk using vxdisksetup. Specifying the public region offset and length allows Veritas to preserve the existing data while allowing flexibility for changes to the private region.
"Reinitializing a disk while preserving existing data"
https://www.veritas.com/docs/000087673
Adding the disk back to the diskgroup with vxdg
(Back to top)
After the disk has been reinitialized, and the status is "online," use vxdg to add it back to the disk group
Figure 6 - Using vxdg to add the disk back to the disk group
|
Syntax: vxdg -g <disk group> -k adddisk <disk media name>=<device access name> Example, with typical output: # vxdg -g datadg -k adddisk datadg02=disk_4
Vxdisk now shows that datadg02 is back in the disk group. Additionally, the "failed was" message is gone. # vxdisk -o alldgs list
|
Was this content helpful?
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.