"WARNING V-5-2-3718 Unable to backup Binary disk group configuration for disk group" is reported by vxconfigbackup

Article: 100002119
Last Published: 2014-01-02
Ratings: 0 0
Product(s): InfoScale & Storage Foundation

Problem

Vxconfigbackup may fail to backup the binary configuration file for disk groups after upgrading to Storage Foundation 5.0

Error Message

Start backing up disk group datadg to /etc/vx/cbr/bk/datadg.1178551889.485.jimmy ...
VxVM vxconfigbackup WARNING V-5-2-3718 Unable to backup Binary disk group configuration for disk group datadg.
VxVM  NOTICE V-5-2-3100 Backup complete for disk group: datadg 

Solution



Problem Summary:

Vxconfigbackup returns an error and creates an empty (zero byte) binconfig file:

# pwd
/etc/vx/cbr/bk/datadg.1178551889.485.jimmy

# ls -l
total 446
-rw-rw-rw-   1 nobody   nobody         0 Jul  2 12:57 1178551889.485.jimmy.binconfig
-rw-rw-rw-   1 nobody   nobody     70959 Jul  2 12:57 1178551889.485.jimmy.cfgrec
-rw-rw-rw-   1 nobody   nobody    122714 Jul  2 12:57 1178551889.485.jimmy.dginfo
-rw-rw-rw-   1 nobody   nobody     33278 Jul  2 12:57 1178551889.485.jimmy.diskinfo



What is the impact of this issue?

This issue will result in a failure of any attempt to restore or recover a failed diskgroup configuration using the 'vxconfigrestore' binary.




The required conditions in which this issue will manifest:

The issue occurs if the diskgroup consists of disks with variable size private region configuration lengths.

After the upgrade to Storage Foundation 5.0, this could be triggered by the addition (ie initialization) of new disks to the disk group  

CONFIG_DISK_STATUS

config_region_len=7448

config_disk EMC%5FSYMMETRIX%5F103696%5F9636B000 c72t4d0 copy=01 len=24072 state=enabled     <<<<---- Notice the size. This will be a disk initialized on a 5.x system
config_disk EMC%5FSYMMETRIX%5F103696%5F9636B000 c72t4d1 copy=01 len=24072 state=enabled
config_disk EMC%5FSYMMETRIX%5F103696%5F961B3000 c72t4d2 copy=01 len=24072 state=enabled
config_disk EMC%5FSYMMETRIX%5F103696%5F9636B000 c72t4d3 copy=01 len=24072 state=enabled
config_disk EMC%5FSYMMETRIX%5F103696%5F961B3000 c72t4d4 copy=01 len=24072 state=enabled
config_disk EMC%5FSYMMETRIX%5F103696%5F961B3000 c72t4d5 copy=01 len=24072 state=enabled
config_disk EMC%5FSYMMETRIX%5F103696%5F9671B000 c72t3d0 copy=01 len=7448 state=disabled     <<<<---- Notice the size. This will be a disk initialized on a 4.x system
config_disk EMC%5FSYMMETRIX%5F103696%5F9671F000 c72t3d1 copy=01 len=7448 state=disabled
config_disk EMC%5FSYMMETRIX%5F103696%5F96723000 c72t3d2 copy=01 len=7448 state=disabled
config_disk EMC%5FSYMMETRIX%5F103696%5F9671B000 c72t3d3 copy=01 len=7448 state=disabled
config_disk EMC%5FSYMMETRIX%5F103696%5F9671F000 c72t3d4 copy=01 len=7448 state=disabled
config_disk EMC%5FSYMMETRIX%5F103696%5F96723000 c72t3d5 copy=01 len=7448 state=disabled
config_disk EMC%5FSYMMETRIX%5F103696%5F96723000 c72t3d6 copy=01 len=7448 state=disabled
config_disk EMC%5FSYMMETRIX%5F103696%5F96723000 c72t3d7 copy=01 len=7448 state=disabled




Problem Explanation:

The problem is such that the vxconfigbackup script is unable to pick the correct disks with enabled configuration copies and hence fails to generate a binary configuration copy for the disks with enabled copies of the private region configuration.

The vxconfigbackup script identifies the diskgroup's "config_region_len=7448", which seems to be the size of the devices with smallest Private Region Configuration of available disks in the diskgroup. These are the disks from the older version of 4.x where the private region size of disks used to be smaller than the private region configuration on disks which would be initialized on Volume Manager version 5.0.

In our situation, all the enabled configuration copies are on disks with Private Region Length 24072, which is larger than 7448. These are the disks that are initialized on Volume Manager version 5.0 and hence having a larger private region configuration size. Since the "config_region_len" of the disk group is 7448, the vxconfigbackup script incorrectly scans only for those disks with Enabled configuration copies and with "config len=7448". The script identifies that all the disks with "config len=7448" are having Disabled configuration copies on the disks and hence fails to backup a valid binary configuration for the disk group in the form of a binconfig file.




Problem Workaround:

Replace all the old disks that have the smaller private region length (in our case all disks having "config len=7448") with new disks by initializing the new devices on Volume Manager 5.0 and moving the data from the old disks to the newly added disks.




Problem Solution:

Veritas has identified this issue as a Product Functionality Bug -e1224659. The following Versions of Storage Foundation contain the fix to this issue:

Veritas Storage Foundation HA 5.0 MP3 RP1 or later on Solaris x86_64
Veritas Storage Foundation HA 5.0 MP3 RP1 or later on Solaris SPARC
Veritas Storage Foundation HA 5.0 MP3 RP2 or later on AIX
Veritas Storage Foundation HA 5.0.1 on HPUX 11.31  

As of the data of writing this document, the fix for Storage Foundation 5.0 on HPUX 11.23 will be included in the forthcoming  5.0 MP2 RP3 patch. This fix check-in is being tracked under e2091195.




Additional Note:

Another important issue to note is that after upgrading to Storage Foundation 5.0, the Volume Manager setting for the default number of vxconfigbackup configuration copies that will be stored on the system is changed to 1 copy only instead of the previous default of 5 copies on 4.x versions. This change was made to reduce the space requirement in the "/etc" filesystem. The size of the default private region configuration for disks initialized on VxVM 5.0 is 32 MB as compared to the 2 MB on previous versions and hence the total amount of space requirement increases to approximately 165 MB  for each disk group with 5 configuration copies multiplied by the total number of disk groups. In previous versions it was only about 15 MB space requirement per disk group. The default to have only one configuration copy is not very useful in case of a problem similar to the one explained in this document above, as we will lose the only good configuration copy and that may lead to a corruption of the single copy, hence making it of no use. Taking this in account and based on the past experience with customers in resolving disk group corruption issues and disk group configuration recovery using the vxconfigbackup/vxconfigrestore mechanism, Veritas Technical Support Teams have discussed with Veritas Engineering Teams to modify the minimum default number to be more than one. it has been decided that the default number will be increased in the next Major version of Storage Foundation on 5.1.
More Details on changing the number of configuration copies which will be backed up using the vxconfigbackup is explained and documented in the following article document:
How to change the number of configuration copies saved in /etc/vx/cbr/bk/<disk_group> directory from default = 1 for all VRTSvxvm 5,x releases ? -   https://www.veritas.com/support/en_US/article.000037727
 

 

References

Etrack : 1224659 Etrack : 2091195

Was this content helpful?