vxconfigbackupd, vxconfigbackup,  and vxconfigrestore  have been  provided for backing up and restoring only configuration data for Volume Manager disk groups, and for Volume Manager objects such as volumes that are configured within the disk groups. They do not back up or restore any user or application data that is contained within volumes or other Volume Manager objects.

Notes:

Restoration of a disk group configuration requires that the same physical disks are used as were configured in the disk group when the backup was taken.

If you use vxdisksetup on a disk, and specify attributes that differ from those in the configuration backup, this may corrupt the public region and any user data therein.

You can also use the configuration data to recreate a disk group on another system if the original system is not available. Take care that you do not overwrite any files on the target system that are in use by a disk group on that system

Location

/etc/vx/bin/vxconfigbackupd: This daemon is executed automatically on reboot as part of the /etc/rc2.d/S95vxvm-recover script and will monitor changes to the Volume Manager configuration and automatically records any configuration changes that occur.

/etc/vx/bin/vxconfigbackup: Execute as required manually (if vxconfigbackupd is not running),  when you require a backup of the configuration data

/etc/vx/bin/vxconfigrestore: Execute as required manually when you require to restore corrupted configuration data

The "-l" option allows you to specify an alternative directory for the location of the backup configuration files other than the default location, /etc/vx/cbr/bk.

Example:

Group:     oradg
dgid:      1071722106.138.gopal
import-id: 1024.375
flags:     cds
version:   110
alignment: 8192 (bytes)
ssb:            on
detach-policy: global
copies:    nconfig=default nlog=default
config:    seqno=0.1078 permlen=1280 free=1267 templen=7 loglen=192
config disk c1t10d0s2 copy 1 len=1280 state=clean online

 

Default backup files :  The disk group =oradg is the name of the disk group, and  dgid = 1071722106.138.gopal is the disk group ID, and they are used in the > as follows:

 

These are the names of the files containing the latest copy configuration backup data in the configuration directory. A further five additional backup copies are also maintained in  a cyclic manner and are named  ., where n is a number ranging from 1 to 5 , where n = 1 is the second most recent copy and n=5 is the oldest copy. In this example, the latest  config file is used to  recreate a vxprint -ht output by using the command:

 

# cat  /etc/vx/cbr/bk/oradg.1071722106.138.gopal/1071722106.138.gopal.cfgrec  |  vxprint -D - -rth  

 

The output will indicate what the restored configuration may look like.

Error:  Typical errors which will prompt to use the vxconfig backup data for restoring.

Any  underlying problem such as failed or disconnected hardware needs to be corrected before proceeding.

Backup:  To run the commands manually when vxconfigbackupd is not running (in this example oradg will be used ):

# vxdg list oradg

To back up a single disk group manually :

# /etc/vx/bin/vxconfigbackup  oradg
Start backing up diskgroup oradg to /etc/vx/cbr/bk/oradg.1071722106.138.gopal ..

To back up all disk groups :
# /etc/vx/bin/vxconfigbackup

V xVM vxconfigbackup ERROR V-5-2-3694 Configuration Copy for diskgroup rootdg has
not changed since last backup (Thu Jan 8 15:55:20 EST 2004).  Backup is not necessary.
Start backing up diskgroup datadg to /etc/vx/cbr/bk/datadg.1075436149.168.gopal...

VxVM  NOTICE V-5-2-3100 Backup complete for diskgroup: datadg

VxVM vxconfigbackup ERROR V-5-2-3694 Configuration Copy for diskgroup oradg has
not changed since last backup (Thu Feb 12 16:19:59 EST 2004).  Backup is not necessary.

To back up to an alternative location of the configuration database:

# /etc/vx/bin/vxconfigbackup -l  /tmp/orgdgbck  oradg
Start backing up diskgroup oradg to /tmp/oradgbck/oradg.1071722106.138.gopal ...
VxVM  NOTICE V-5-2-3100 Backup complete for diskgroup: oradg

To activate and check if vxconfigbackupd is running,  enter :

# /usr/bin/vxconfigbackupd &
# ps -edf | grep "vxconfigbackupd"
   root 27423 27168  0 16:37:50 ?        0:00 /sbin/sh - /etc/vx/bin/vxconfigbackupd
   root 27168     1  0 16:37:46 ?        0:00 /sbin/sh - /etc/vx/bin/vxconfigbackupd

 

Restore:  None of the disks or Volume Manager objects in the disk group may be open or in use by any application while the restoration is being performed. Disks that are in use or whose layout has been changed are excluded from the restoration process. The restoration process has two stages: precommit and commit.

 

Precommit:  Examines 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 of the disks' private region headers are invalid and need to be reinstalled at this stage.

 

To reinstalls the disk headers where these have become corrupted:

or

# /etc/vx/bin/vxconfigrestore -p -l /tmp/oradgbck oradg  (using alternative database location and disk group name )

 

Alternatively, to specify that the disk headers are not to be reinstalled, replace the "-p" option with "-n":

 

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

After executing the precommit command, use  the vxprint output to examine the configuration that the restored disk group will have before proceeding. At this stage,  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.  Once completed,  check the status of the disk group using:

# vxdg list oradg
Group:     oradg
dgid:      1071722106.138.gopal
import-id: 1024.375
flags:     cds restoring
 

The  "restoring" flag is set once the vxconfigrestore has completed successfully.

Abandon (optional) : Cancel/Abort  the restoration at the precommit stage:  

 

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

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. Once completed,  the "restoring" flag no longer exists.  

 

Troubleshooting:  If disks have been replaced on a system,  there may exist several conflicting backups for a disk group. You see a message similar to the following from the vxconfigrestore command:

Solution : The backup file /etc/vx/cbr/bk/diskgroup. dgid/ dgid.dginfo contains a time stamp that records when the backup was taken..The following is a sample extract from such a backup file that shows the time stamp and disk group ID information:

TIMESTAMP
Tue Oct 15 23:27:01 PDT 2003

DISK_GROUP_CONFIGURATION
Group: mydg
dgid: 1047336696.19.xxx.veritas.com

Use the time stamp information to decide which backup contains the relevant information, and use the disk group ID instead of the disk group name:

# /etc/vx/bin/vxconfigrestore -p  1047336696.19.xxx.veritas.com
 

 

How the vxconfigbackupd daemon backs up the disk group configuration data

Vxconfigbackupd monitors changes to disk group configuration in Volume Manager whenever a configuration change occurs, and stores the output in the configuration directory. This will assist recovery of lost or corrupt disk groups/volumes when they do not have backup copies of their configuration (old vxprint output).

The vxconfigbackupd daemon is started from the /etc/rc2.d/S95vxvm-recover startup script. The script includes the following additional lines:

# Starting vxconfigbackupd.
#
#/etc/vx/bin/vxconfigbackupd &

The error messages as well as the warning messages for the daemon are written with a timestamp to the console device.



Usage
 

-d  
To identify an alternate configuration data backup directory

Default: The configuration files are stored in /etc/vx/dgcfg.


-n
Number of copies that are maintained and stored in gzip, compress, or ASCII text, depending on which utility is available on the system. The configuration copy files are maintained in a cyclic manner and are named dgname.n, where n is a number ranging from 1 to n.

Default: Five copies are stored, where n=1 is the most recent copy and n=5 is the oldest copy.


-R
The configuration files for the disk group are removed from the backup directory when a disk group is deported or destroyed.

Default: Files are moved to the /etc/vex/dgcfg/deport subdirectory (created as default after the first disk group is deported or destroyed).



To restrict the daemon logging for specified disk groups

Default: The daemon logs all imported disk groups.


If the default setting is to be changed, stop/start vxconfigbackupd with the new options as follows:

# ps -edf | grep vxconfigbackupd
   root 28899 25665  1 16:37:00 pts/3    0:00 /bin/ksh /etc/vx/bin/vxconfigbackupd

# pkill vxconfigbackupd

#/etc/vx/bin/vxconfigbackupd  [ -d dir ] [ -n num ] [ -R ] [ dg_name ... ]  &

For more details, refer to the vxconfigbackupd (1M) manual page.

Note: Currently, there is no vxconfigrestore utility to restore the "saved" data.

 

The configuration data stored in the files is the result of executing the command:
 

#  vxprint -g -m

The -m option displays all information about each selected record in a format that is useful as input to both the vxmake utility and to awk(1) scripts.




Recovery

The configuration data can be accessed from the default directory as follows (assuming that the disk group newdg has been created, more than five changes have been executed against the disk group):

# cd /etc/vx/dgcfg
# ls -lrt newdg*
-rw-r--r--   1 root     root        6019 Nov  7 16:26 newdg.5
-rw-r--r--   1 root     root        6001 Nov  7 16:26 newdg.4
-rw-r--r--   1 root     root       18034 Nov  7 16:27 newdg.3
-rw-r--r--   1 root     root       18034 Nov  7 16:27 newdg.2
-rw-r--r--   1 root     other       2035 Nov  7 16:53 newdg.1
 

# file newdg*
newdg.1:        gzip compressed data - deflate method
newdg.2:        compressed data block compressed 16 bits
newdg.3:        compressed data block compressed 16 bits
newdg.4:        ascii text
newdg.5:        ascii text

Normally, all the files will be either in gzip, compressed, or ASCII text format.

This example illustrates how to access all the three possible formats (convert them back to ASCII text).
 

File newdg.4  (ASCII text - no action required)

# cat "newdg.4"

 
File newdg.2  (compressed)

# mv newdg.2 newdg.2.Z

# uncompress newdg.2.Z
# cat "newdg.2"


File newdg.1 (gzip)

# gunzip -S .1 newdg
# cat "newdg"


This information can now be used as part of the vxmake or scripts utility to recreate disk groups, subdisks, plexes, and volume records for Volume Manager.