TSM lets a server (a source server) store the results of database backups, export operations, storage pool operations, and a DRM PREPARE command on another server (a target server). The data is stored as virtual volumes, which appear to be sequential media volumes on the source server but which are actually stored as archive files on a target server. Virtual volumes can be any of the following:
The source server is a client of the target server, and the data for the source server is managed only by the source server. In other words, the source server controls the expiration and deletion of the files that comprise the virtual volumes on the target server.
At the target server, the virtual volumes from the source server are seen as archive data. The source server is registered as a client node (of TYPE=SERVER) at the target server and is assigned to a policy domain. The archive copy group of the default management class of that domain specifies the storage pool for the data from the source server.
Note: | If the default management class does not include an archive copy group, data cannot be stored on the target server. |
Using virtual volumes can benefit you in the following ways:
Be aware of the following when you use virtual volumes:
In the source/target relationship, the source server is defined as a client node of the target server. To set up this relationship, a number of steps must be performed at the two servers. In the following example (illustrated in Figure 58), the source server is named DELHI and the target server is named TOKYO.
Register the source server as a client node. The target server can use an existing policy domain and storage pool for the data from the source server. However, you can define a separate management policy and storage pool for the source server. Doing so can provide more control over storage pool resources.
define stgpool sourcepool autotapeclass maxscratch=20
copy domain standard sourcedomain
update copygroup sourcedomain standard standard type=archive destination=sourcepool
After issuing these commands, ensure that you assign the source server to the new policy domain (UPDATE NODE) and activate the policy. See Changing Policy with the Active Policy Set for details.
Figure 58. Communication configuration for virtual volumes
You can perform certain operations at the source server that cause data to be stored in a storage pool at the target server. These operations are:
The following sections describe how to perform these operations. In the examples, the following is assumed:
You can back up the database of a source server to a target server. For example, to perform an incremental backup of the source server and send the volumes to the target server, issue the following command:
backup db type=incremental devclass=targetclass
Expiration Processing of Database Backup Volumes and Recovery Plan Files with the Tivoli Disaster Recovery Manager: If your server is licensed for DRM, expiration processing can delete volumes containing expired database backups and recovery plan files. One or more database backup volumes may be deleted from the volume history during expiration processing if the following conditions are true:
See Moving Backup Volumes Onsite for more information.
You can also do an automatic database backup to a target server. For example, if you have issued the following command, a database backup occurs automatically when more than 60 percent of recovery log space is used:
define dbbackuptrigger devclass=targetclass logfullpct=60
You can back up a storage pool of a source server to a target server. For example, a primary storage pool named TAPEPOOL is on the source server. You can define a copy storage pool named TARGETCOPYPOOL, also on the source server. TARGETCOPYPOOL must have an associated device class whose device type is SERVER. When you back up TAPEPOOL to TARGETCOPYPOOL, the backup is sent to the target server. To do so, issue the following commands:
define stgpool targetcopypool targetclass pooltype=copy maxscratch=20
backup stgpool tapepool targetcopypool
You can configure your TSM system so that when client nodes registered to the source server back up, archive, or migrate their data, that data is sent to the target server. When clients restore, retrieve, or recall their data, the source server gets the data from the target server.
To configure your system, ensure that the management policy for those nodes specifies a storage pool that has a device class whose device type is SERVER. For example, the following command defines the storage pool named TARGETPOOL.
define stgpool targetpool targetclass maxscratch=20 reclaim=100
Note: | Reclamation of a storage pool automatically begins when the percentage of reclaimable space, which is specified by the RECLAIM parameter, is reached. Reclamation of a target storage pool can involve the movement of a great deal of data from the target server to the source server and back to the target. If this operation occurs automatically during peak operating periods, it could slow network performance significantly. If you set the value to 100, reclamation will not occur automatically. For details about storage pool reclamation and how to begin it manually, see Reclaiming Space in Sequential Access Storage Pools. |
You can set up your storage pool hierarchy so that client data is migrated from a storage pool on the source server to the target server. For example, storage pool TAPEPOOL is on the source server. The TAPEPOOL definition specifies NEXTSTGPOOL=TARGETPOOL. TARGETPOOL has been defined on the source server as a storage pool of device type SERVER. When data is migrated from TAPEPOOL, it is sent to the target server.
define stgpool tapepool tapeclass nextstgpool=targetpool maxscratch=20
You can use any of the TSM EXPORT commands to export data from one TSM source server to sequential media on a target TSM server. You must specify a device class with a device type specified as SERVER. For example, to copy server information directly to a target server, issue the following command:
export server devclass=targetclass
If data has been exported from a source server to a target server, you can import that data from the target server to a third server. The server that will import the data uses the node ID and password of the source server to open a session with the target server. That session is in read-only mode because the third server does not have the proper verification code.
For example, to import server information from a target server, issue the following command:
import server devclass=targetclass
If you have restored the database on the source or target server, you should perform reconciliation between the virtual volumes on the source server and the archive files on the target server. You should also perform reconciliation if you have any other reason to suspect inconsistencies. For example, frequent communication errors between target and source servers could introduce a problem.
To perform reconciliation, issue the RECONCILE VOLUMES command specifying a device class of the device type of SERVER. In the following example TARGETCLASS is a server device class:
reconcile volumes targetclass fix=yes
The reconciliation action is determined by the FIX parameter as shown in
the following table:
FIX= | At the Source Server | At the Target Server | Action |
---|---|---|---|
NO | Volumes exist | No files exist | Report error |
Files exist but are marked for deletion | |||
Active files exist but attributes do not match | |||
Volumes do not exist | Active files exist | Report error | |
Files exist but are marked for deletion | None | ||
YES | Volumes exist | No files exist | Report error
For storage pool volumes: Mark volumes as unavailable |
Files exist but marked for deletion | Report error
For storage pool volumes: If attributes match, mark files on the target server as active again, mark volumes on the source server as unavailable, and recommend that an AUDIT VOLUME be done to further verify the data. If attributes do not match, mark volumes as unavailable. | ||
Active files exist but attributes do not match | Report error
For storage pool volumes: Mark volumes as unavailable and recommend that an AUDIT VOLUME be done to further verify the data. | ||
Volumes do not exist | Active files exist | Mark files for deletion on the target server. | |
Files exist but marked for deletion | None |