Administrator's Guide
ADSM lets a server (source server) store the results of database
backups, export operations, and storage pool operations on another server
(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. 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:
- The source server can use the target server as an electronic vault for
rapid recovery from a disaster.
- Smaller ADSM source servers can use the storage pools and tape devices of
larger ADSM servers.
- For incremental database backups it can decrease wasted space on volumes
and under use of high-end tape drives.
Be aware of the following when you use virtual volumes:
- 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 this is the only way
databases are backed up, if both servers are at the same location, and if a
disaster strikes that location, you may have no backups with which to restore
your databases.
- Moving large amounts of data between the servers may slow down your
communications significantly, depending on the network bandwidth and
availability.
-
You can specify in the device class definition (DEVTYPE=SERVER) how often and
for how long a time the source server will try to contact the target
server. Keep in mind that frequent attempts to contact the target
server over an extended period can affect your communications.
- Under certain circumstances, inconsistencies may 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 (see "Reconciling Virtual Volumes and Archive Files" for details).
- Storage space limitations on the target server affect the amount of data
that you can store on that server.
- To minimize mount wait times, the total mount limit for all server
definitions that specify the target server should not exceed the mount total
limit at the target server. For example, a source server has two device
classes, each specifying a mount limit of 2. A target server has only
two tape drives. In this case, the source server mount requests could
exceed the target server's tape drives.
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.
|
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]