Top
ETERNUS SF AdvancedCopy Manager V15.1 Operation Guide
ETERNUS

3.9.2 Backup operation in units of physical disks

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.


3.9.2.1 Operational configuration

Configure disk groups that are to be used as transaction volumes or backup volumes.

Observe the following conditions when configuring the disk groups:

Figure 3.16 Transaction volume and backup volume


3.9.2.2 Preparations


3.9.2.2.1 Confirming the disk group configuration information file

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>

3.9.2.2.2 Setting the transaction volume and backup volume

When configuring the transaction and backup volumes, all disks in the volume group must be specified.

Example:
# /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
#

3.9.2.2.3 Preparing a device map file

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.

Example of a device map file
# 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".


3.9.2.3 Backup

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.

Example of snapshot backup
(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.)
Example of synchronous backup
(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.

Table 3.8 Pre-processing and post-processing for backup

Volume type

Pre-processing

Post-processing

Transaction
volume

  1. Secure data integrity by stopping access to all logical volumes in the disk group.

  2. If file systems are included, unmount all file systems in the disk group.

  3. Import the disk group, when the disk group is not imported.

  1. If file systems are included, mount the volumes that were unmounted during preprocessing.

Backup
volume

  1. Stop access to all logical volumes in the disk group.

  2. If file systems are included, unmount all file systems in the disk group.

  3. Deport the disk group.

  4. A disk group subordinate's physical disk is set to offline.

  1. The physical disk set to offline with preprocessing is set to online.

  2. Reconfigure the disk group.

  3. If file systems are included, remount the volumes that were unmounted during preprocessing.


Reconfiguring the disk group

Reconfigure the disk group as follows:

  1. 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.
    #
  2. 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.


3.9.2.4 Restoration

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.

Example of restoration
(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.

Table 3.9 Pre-processing and post-processing for restoration

Volume type

Pre-processing

Post-processing

Backup
volume

  1. Secure data integrity by stopping access to all logical volumes in the disk group.

  2. Import the disk group, when the disk group is not imported.

Post-processing is not required.

Restoration
destination
volume

  1. Stop access to all logical volumes in the disk group.

  2. If file systems are included, unmount all file systems in the disk group.

  3. Deport the disk group.

  4. A disk group subordinate's physical disk is set to offline.

  1. The physical disk set to offline with pre-processing is set to online.

  2. Reconfigure the disk group.

  3. If file systems are included, remount the volumes that were unmounted by preprocessing.

Reconfiguring the disk group

Reconfigure the disk group as follows:

  1. 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.
    #
  2. 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.