Tivoli Header

Administrator's Guide


Using Virtual Volumes to Store Data on Another Server

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:

Note:
When you issue a DEFINE SERVER command, the source server sends a verification code to the target server. When the source server begins a session with the target server, it also sends the verification code. If the code matches what was previously stored on the target, the session is opened in read/write mode. If the verification code is lost at the source server (for example, after a database restore), the code can be reset by issuing an UPDATE SERVER command with the FORCESYNC=YES parameter.

Setting Up Source and Target Servers for 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 83), the source server is named DELHI and the target server is named TOKYO.

Figure 83. Communication configuration for virtual volumes


Performing Operations at the Source Server

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:

Back Up the Database

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

Back Up a Storage Pool

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 

Store Client Data on a Target Server

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.

Migrate Data from a Source Server Storage Pool to a Target Server Storage Pool

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

Export Server Information to a Target Server

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

Import Server Information from a Target Server

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

Reconciling Virtual Volumes and Archive Files

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


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]