You can store the results of database backups and other
items on another server as a virtual volume.
About this task
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.