Storix Software SBAdmin TSM Edition Users Guide - Manual (Page 15)

Storix System Backup Administrator 15 Version 8.2 TSM Edition User Guide
SBAdmin utilizes the TSM Client API (application program interface), also referred to as an application client
within some TSM documentation. Backups performed within TSM use the TSM Backup/Archive client. These
backups differ from those performed with SBAdmin using the API client. Backups performed by TSM are not
visible within SBAdmin, and SBAdmin backups to the TSM server are not viewable within TSM. However, the
same policies which apply to other TSM management classes and storage pools may also apply to SBAdmin
backups.
TSM Backup Retention
SBAdmin writes backups to the “SBADMIN” Management Class, which must be defined on the TSM
server. Having a separate management class for SBAdmin backups ensures that certain required policies
are enforced, and allows you to assign a separate storage pool to SBAdmin backups than those used for
other TSM backups.
While other TSM backups place each separate file in a backup image, and provide version control for each
individual file, SBAdmin backups use a single image for each filesystem or raw device (i.e. logical volume
or partition) that is backed up. SBAdmin backups, therefore, contain much less catalog space on the TSM
server, and add little management workload to the server.
SBAdmin backups do not allow versioning control by the TSM server. This is because each SBAdmin
backup has a unique object name. SBAdmin backup retention policies will provide the ability to control the
number of backups retained on the server, as well as the age of the backups. Backups are automatically
deleted from the server only when replaced by more recent backups.
Shared Versus Owner Access
SBAdmin backups to a TSM server may be designated as either shared access or owner access when the
backup is created. Backups created with shared access may be restored by any other client (node). This
provides the ability to create master backups which may be used for cloning, provisioning, or migration of
operating systems, volume groups, filesystems, etc, to different hardware. If a backup is created with owner
access, only the original node will be able to read from that backup.
TSM Server Authentication
The TSM Admin System configured for SBAdmin must be a TSM node itself (may also be the server). On
the admin system, you will define the TSM clients (nodes) and the TSM servers. SBAdmin does not use
the TSM client options file (dsm.opt) nor the TSM client system options file (dsm.sys) defined for other
applications. Instead, all clients and servers are defined on a single system (the admin system) and are
copied to the clients as needed.
When a server is defined on the admin system, a TSM Administrative User name and password must be
defined also. This TSM Administrative user must have been previously configured within TSM to have
System, Storage or Policy authority. This administrative user will be used to manage the backups
performed by SBAdmin. The administrative username and password is stored in a protected and encrypted
file on the admin system and is never sent over the network or saved on any of the clients.
Client passwords must be defined on the admin system if the node uses PASSWORDAccess “ prompt” to
access the server. In this case, the node password will be copied from the admin system to a protected file
on the client and passed to the server whenever the client accesses the server. If the node uses
PASSWORDAccess “
generate”, the node password need not be defined on the admin system (assuming
the node has previously accessed the server and therefore has already created a TSM encrypted password
file. This is the preferred method of server authentication since it does not require the admin system to
store a copy of each node’s password.