When the VxVM volume configuration does not satisfy the conditions for backup operation using units in logical volumes, backup operation can be performed using units of physical disks.
When backup operation is performed in units of physical disks, disk group integrity must be maintained and, therefore, all the physical disks in the disk group must be processed synchronously.
Point
For the physical volume which should be synchronized, confirm it by using either Web Console or stgxfwcmdispdev (Device information display command).
Note
It is only VM disk of the "nopriv" type that a physical slice becomes the unit of management.
Before starting this operation, be sure to understand the basic operation of ordinary volumes.
Snapshot backup is recommended for backing up in units of physical disks. In the case of synchronized backup, commands that access the destination volume, such as VxVM commands cannot be used during full copy or differential copy.
For operation in a cluster configuration, the device name (/dev/(r)dsk/c#t#d#) of the physical disks that comprise the disk group must be the same at all servers that comprise the cluster, and the ETERNUS Disk storage system's disk indicated by the device name must be the same.
For operation in a SunCluster environment, the VxVM enclosure name must be the same at all servers that comprise the cluster, and the ETERNUS Disk storage system's disk indicated by the enclosure name must be the same.
Configure disk groups that are to be used as transaction volumes or backup volumes.
Observe the following conditions when configuring the disk groups:
The number, sizes, and types of VM disks must be the same.
The configurations of logical volumes must be the same.
The disk group must be reconfigured in backup post-processing. Confirm that a volume group configuration information file has been saved in the following format.
/etc/vx/cbr/bk/<disk group name>.<disk group ID> |
When configuring the transaction and backup volumes, all disks in the volume group must be specified.
# /opt/FJSVswsts/bin/swstdevinfoset -t /dev/vx/dmp/c1t0d10s2 swstdevinfoset completed # /opt/FJSVswsts/bin/swstdevinfoset -t /dev/vx/dmp/c1t0d11s2 swstdevinfoset completed # /opt/FJSVswsts/bin/swstdevinfoset -b /dev/vx/dmp/c1t0d20s2 swstdevinfoset completed # /opt/FJSVswsts/bin/swstdevinfoset -b /dev/vx/dmp/c1t0d21s2 swstdevinfoset completed #
For the backup operation of a VxVM volume, a device map file must be created because a backup volume in the same volume structure as the transaction volume must be specified.
# Transaction volume Backup volume /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d20s2 /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d21s2
For details on the device map file, refer to "3.4.9 Preparing a device map file".
Before performing backup operation, all physical disks in the disk group must be synchronized.
Perform the required pre-processing and/or post-processing work for each volume group. Disable pre-processing and post-processing when operating individual physical disks.
(Perform pre-processing for the transaction and backup volumes.) # /opt/FJSVswsts/bin/swstbackup /dev/vx/dmp/c1t0d10s2 -Xdevmap /acm/devmap.txt /dev/vx/dmp/c1t0d10s2 swstbackup completed # /opt/FJSVswsts/bin/swstbackup /dev/vx/dmp/c1t0d11s2 -Xdevmap /acm/devmap.txt /dev/vx/dmp/c1t0d11s2 swstbackup completed # (Perform post-processing for the transaction and backup volumes.)
(Perform pre-processing for the backup volumes.) # /opt/FJSVswsts/bin/swststartsync /dev/vx/dmp/c1t0d10s2 -Xdevmap /acm/devmap.txt /dev/vx/dmp/c1t0d10s2 swststartsync completed # /opt/FJSVswsts/bin/swststartsync /dev/vx/dmp/c1t0d11s2 -Xdevmap /acm/devmap.txt /dev/vx/dmp/c1t0d11s2 swstsstartsync completed # (After state of equivalency upkeep) (Perform pre-processing for the transaction volumes.) # /opt/FJSVswsts/bin/swstbackup /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d10s2 swstbackup completed # /opt/FJSVswsts/bin/swstbackup /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d11s2 swstbackup completed # (Perform post-processing for the transaction and backup volumes.)
The table below summarizes the pre-processing and post-processing work to be performed before and after backup.
Volume type | Pre-processing | Post-processing |
---|---|---|
Transaction |
|
|
Backup |
|
|
Reconfiguring the disk group
Reconfigure the disk group as follows:
Pre-commit analysis for restoration
# /etc/vx/bin/vxconfigrestore -p dstdg Diskgroup dstdg configuration restoration started ...... Installing volume manager disk header for c1t0d20s2 ... Installing volume manager disk header for c1t0d21s2 ... - dstdg's diskgroup configuration is restored (in precommit state). Diskgroup can be accessed in read only and can be examined using vxprint in this state. Run: vxconfigrestore -c dstdg ==> to commit the restoration. vxconfigrestore -d dstdg ==> to abort the restoration. # |
Commit the change required for restoring the configuration of the copy destination disk group.
# /etc/vx/bin/vxconfigrestore -c dstdg Committing configuration restoration for diskgroup dstdg .... dstdg's diskgroup configuration restoration is committed. # |
Note
In the case of a clustered system, when a disk group or a mount resource has been defined, instead of using the import/deport command for the disk group use the online/offline process.
If a mount point is defined as a cluster resource, instead of using the file system mount/unmount commands use the mount resource online/offline processing.
When performing a system disk exchange, there are cases when conflicting backup configuration information may exist.
In such cases, the disk group ID needs to be reset after executing the above command.
After this operation, where the volumes within a disk group are required to be run in synchronous mode in background, synchronous processing may take some time depending on the volume configuration.
It is also possible to use the volumes during this time.
All physical disks in the disk group must first be synchronized to perform this operation.
Perform the required pre-processing or post-processing work for each disk group as necessary. Disable pre-processing and post-processing when using individual physical disks.
(Perform pre-processing for the transaction and backup volumes.) # /opt/FJSVswsts/bin/swstrestore /dev/vx/dmp/c1t0d10s2 /dev/vx/dmp/c1t0d10s2 swstrestore completed # /opt/FJSVswsts/bin/swstrestore /dev/vx/dmp/c1t0d11s2 /dev/vx/dmp/c1t0d11s2 swstrestore completed # (Perform post-processing for the transaction and backup volumes.)
The table below summarizes the pre-processing and post-processing work to be performed before and after restoration.
Volume type | Pre-processing | Post-processing |
---|---|---|
Backup |
| Post-processing is not required. |
Restoration |
|
|
Reconfiguring the disk group
Reconfigure the disk group as follows:
Restoration pre-commit analysis
# /etc/vx/bin/vxconfigrestore -p srcdg Diskgroup srcdg configuration restoration started ...... Installing volume manager disk header for c1t0d10s2 ... Installing volume manager disk header for c1t0d11s2 ... - srcdg's diskgroup configuration is restored (in precommit state). Diskgroup can be accessed in read only and can be examined using vxprint in this state. Run: vxconfigrestore -c srcdg ==> to commit the restoration. vxconfigrestore -d srcdg ==> to abort the restoration. # |
Commit the change required for restoring the configuration of the copy destination disk group.
# /etc/vx/bin/vxconfigrestore -c srcdg Committing configuration restoration for diskgroup srcdg .... srcdg's diskgroup configuration restoration is committed. # |
Note
In case of a clustered system, when a disk group or a mount resource has been defined, instead of using the import/deport command for the disk group use the online/offline process.
If a mount point has been defined as a clustered system resource, instead of using the file system mount/unmount commands use the mount resource online/offline processing.
When performing a system disk exchange, there are cases when conflicting backup configuration information may exist.
In such cases, the disk group ID needs to be reset after executing the above command.
After this operation, where the volumes within a disk group are required to be run in synchronous mode in background, synchronous processing it may take some time depending on the volume configuration.
It is also possible to use the volumes during this time.