[tab name='About Configuration Backup']

Disk group configuration backup and restoration allows you to backup and restore all configuration data for Veritas Volume Manager (VxVM) disk groups, and for VxVM objects such as volumes that are configured within the disk groups. Using  this feature, you can recover from corruption of a disk group’s configuration that is stored as metadata in the private region of a VM disk. After the disk group configuration has been restored, and the volume enabled, the user data in the public region is available again without the need to restore this from backup media.

[/tab]
[tab name='Backup Procedure']

VxVM uses the disk group configuration daemon to monitor the configuration of disk groups, and to back up the configuration whenever it is changed. By default,the five most recent backups are preserved. If required, you can also back up a disk group configuration by running the vxconfigbackup command.

The following files record disk group configuration information:

/etc/vx/cbr/bk/diskgroup.dgid/dgid.dginfo Disk group information.

/etc/vx/cbr/bk/diskgroup.dgid/dgid.diskinfo Disk attributes.

/etc/vx/cbr/bk/diskgroup.dgid/dgid.binconfig Binary configuration copy.

/etc/vx/cbr/bk/diskgroup.dgid/dgid.cfgrec Configuration records in vxprint -m format.

Here diskgroup is the name of the disk group, and dgid is the disk group ID. If a disk group is to be recreated on another system, copy these files to that system.

To back up a disk group configuration, type the following command:

# /etc/vx/bin/vxconfigbackup diskgroup

To back up all disk groups, use this version of the command:

# /etc/vx/bin/vxconfigbackup

[/tab]
[tab name='Restore Procedure']

You can use the vxconfigrestore utility to restore or recreate a disk group from its configuration backup. The restoration process consists of a precommit operation followed by a commit operation. At 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 the precommit stage.  If any of the disks’ private region headers are invalid, restoration may not be possible without reinstalling the headers for the affected disks.

To perform the precommit operation

Use the following command to perform a precommit analysis of the state of the disk group configuration, and to reinstall the disk headers where these have become corrupted:

# /etc/vx/bin/vxconfigrestore -p [-l directory]  {diskgroup | dgid}

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.

To specify that the disk headers are not to be reinstalled

Type the following command:

# /etc/vx/bin/vxconfigrestore -n [-l directory] {diskgroup | dgid}

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

Type the following command:

# /etc/vx/bin/vxconfigrestore -d [-l directory] {diskgroup | dgid}

To perform the commit operation

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

# /etc/vx/bin/vxconfigrestore -c [-l directory] {diskgroup | dgid}

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. Disks that are in use or whose layout has been changed are excluded from the restoration process.

[/tab]

[endtab]

When trying to access a soft partition after a disk replacement, the metareplace command or any direct I/O to a soft partition will fail with the following types of errors: Read Full

First, an explanation of the time stamps:

mtime - time the contents of file was last modified (written to).
atime - time the file was last used/accessed (read or executed)
ctime - time the inode of the file was last changed (like changing permissions).
ctime also gets updated every time mtime is modified, but not when the atime is changed.
ctime, is NOT the files creation date.   Creation date is NOT recorded  anywhere in the Unix file system.

 Read Full

Below instruction help you to understand, analyse and troubleshoot the problems with  Samba service Read Full

In the global zone view the SMCsudo and SMCtop packages:

1. cd /export/home/student/zones

pkginfo -d sudo-1.6.8p4-sol10-zones-sparc-local
application SMCsudo sudo
#
pkginfo -d top-3.5.1-sol10-zones-sparc-local
application SMCtop top
#

Notice the “false” setting for SUNW_PKG_ALLZONES variable:

pkgparam -d sudo-1.6.8p4-sol10-zones-sparc-local SMCsudo SUNW_PKG_ALLZONES
false
#
pkgparam -d top-3.5.1-sol10-zones-sparc-local SMCtop SUNW_PKG_ALLZONES
false
#

Read Full

This procedure demonstrates how to easily use the “luxadm” command to set the “boot-device” Open Boot Prom (OBP) parameter from a system booted from cdrom or in single user mode. Read Full