You can store the results of database backups and other items on another server as a virtual volume.
About this task
Tivoli® Storage
Manager allows
a server (a source server) to store these items on another
server (a target server):
- Database backups
- Export operations
- Storage pool operations
DRM PREPARE command
- Database backups
- Storage pool backups
- Data that is backed up, archived, or space managed from client nodes
- Client data that is migrated from storage pools on the source server
- Any data that can be moved by EXPORT and IMPORT commands
- DRM plan files
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. You cannot use virtual volumes when the source server and the target server are on the same Tivoli Storage Manager 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.
You
can benefit from the use of virtual volumes in the following ways:
- Smaller Tivoli Storage Manager source servers can use the storage pools and tape devices of larger Tivoli Storage Manager servers.
- For incremental database backups, virtual volumes can decrease wasted space on volumes and under-utilization of high-end tape drives.
- The source server can use the target server as an electronic vault for recovery from a disaster.
Be aware of the following conditions when you use virtual
volumes:
- When you copy or move data from a deduplicated storage pool to a non-deduplicated storage pool that uses virtual volumes, the data is reconstructed. However, after the data movement or copy operation, the amount of data that is reported as moved or copied is the amount of deduplicated data. For example, if a storage pool contains 20 GB of deduplicated data that represents 50 GB of total file data. If the data is moved or copied, the server reports that 20 GB was moved or copied, even though 50 GB of data was sent.
- If you use virtual volumes for database backups, you might have the following situation: SERVER_A backs up its database to SERVER_B, and SERVER_B backs up its database to SERVER_A. If databases are backed up in that manner, if both servers are at the same location, and if a disaster occurs that location, you might have no backups with which to restore your databases.
- You cannot use a Centera storage pool as the target for virtual volumes.
- Under certain circumstances, inconsistencies might arise among virtual volume definitions on the source server and the archive files on the target server. You can use the RECONCILE VOLUMES command to reconcile these inconsistencies.
- To enable data validation between a source and target server, issuing both the DEFINE SERVER and REGISTER NODE commands. For more information, see Validating a node's data and Administrator's Reference.
- Storage space limitations on the target server affect the amount of data that you can store on that server.
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),
you can reset the code by issuing the UPDATE SERVER command
with the FORCESYNC parameter set to YES.
For details, see Reconciling virtual volumes and archive files.