Beruflich Dokumente
Kultur Dokumente
What are the Tivoli Storage Manager Library manager and library
clients in TSM SAN environment:
TSM Library Manager and TSM Library Client methods are used in the Tivoli Storage Manager environment
where a single Tape Library has to be shared among 2 or more TSM Servers and Storage Agents in a SAN
environment. Sharing a tape library means that multiple TSM Servers will use the tape drives of a library for
their operations at the same time. Because only one drive can be used by one server at a time, there has to be
someone who controls the access to the physical devices.
This is done by serializing the access to the devices. In addition to the control of the devices the library manager
also has to control the status, ownership and location of the tape volumes inside the tape library. The
library manager is the only Tivoli Storage Manager server with the inventory information of the shared tape
library. The library manager is the only Tivoli Storage Manager server who knows all volumes that are inside a
library. To learn how to configure Library Manager and Library Client visit this page How to Configure TSM
Library Manager and TSM Library Clients in SAN Environment
The library manager is the only Tivoli Storage Manager server which performs operations to the library. The
task of the library manager is to physically control the library. All the communication with the library is done by
this server. The library manager will also serialize the access to the tape drives, so that only one server is using
a tape drive at the same time.
The checkin and checkout of volumes will be performed by the library manager only. This server is the only
server with a library inventory table for that library. The ownership is added to the inventory table to keep
track which tape belongs to a certain library client. This is the only server in the environment that knows all the
volumes. The library manager can also use the library for its own purposes, without being a library client at the
same time.
Library initialization
Since the library manager is the only Tivoli Storage Manager server which interacts with the library, the
initialization will be done by this server during the start-up process of the server.
Volume mount/dismount
The library manager can be contacted by the clients which send mount and unmount requests. These requests
will be carried out, and afterwards, a response will be sent to the clients.
Checkin/Checkout Volumes
Only the library manager can checkin and checkout out tape volumes. The clients do not have the right to
perform a checkin or checkout command.
Auditing Library
The library inventory is maintained only on the library manager. The audit process on the library manager
checks the presence of the volumes and the actual slot locations.
What is Tivoli Storage Manager(TSM) Library clients in SAN Environment:
The library client uses the Library Manager for the handling of the physical hardware. The client send the
requests to the library manager, and afterwards reads or writes to the tape drive it was given access to.
To send requests from the library client to the library manager, and to send the response from the manager to
the client, the server-to-server communication protocol is used. That means that a TCP/IP connection is
necessary and the two Tivoli Storage Manager servers must be configured to each other. In an environment
with multiple library clients, there is no need to have each Tivoli Storage Manager server configured to every
other Tivoli Storage Manager server,
because the communication has always been done directly with the library manager.
No library client has access to the library in the same way that it can control the gripper to mount a volume.
The library client has to send a request to the library manager, which controls the library and mounts volumes.
If a new volume is needed the library client sends a request to the library manager. The library manager
chooses a scratch tape and updates the ownership of the tape. After doing this a response is send to the client,
and the client then can issue a mount request in order to use the volume.
If a volume is not used any more, the library client sends a release request to the library manager and the tape
will be returned to the scratch pool.
The audit library operations are used to update the library manager’s inventory information. The library client
sends the library manager the name of the tapes it is using, so that the ownership of the tape volume can be
updated in the library inventory table of Library Manager.
The library client has no library inventory table for a shared library. Even so, storage pool volumes can be seen
with the query volume command, and database backup volumes can be seen with the query
volhistory command. The DRM volumes table can also be queried.
Steps to Follow to Configure TSM Library Manager and TSM Library Clients:
Below table describes the high-level steps involved to configure Tape Library sharing in a Multiple TSM Server
Environment. You can get detailed steps in TSM Administrator Guide Book. The most important prerequisites
to use this feature is that the library manager must be at a higher Tivoli Storage Manager version than the
library clients. For example, a Tivoli Storage Manager 6.3 server cannot be a library client to a Tivoli Storage
Manager 6.1 library manager.
4) Define the path for the drive(s). 13) Define the storage pool
The Library manager receives the requests from the library clients and physically controls the library operations
like mount/dismount, checkin / checkout and labeling tape volumes. The Library Manager has the ability to
control the status, ownership and location of all the tape volumes inside the tape library.
To send requests from the library client to the library manager, and to send the response from the manager to
the client, the server-to-server communication protocol is used. That means that a TCP/IP connection is
necessary and the two Tivoli Storage Manager servers must be configured to each other
The following steps are required for Tivoli Storage Manager Servers to share library resources on a SAN:
Ensure the server that will be defined as the library manager is at the same or higher version as the TSM
servers that will be defined as library clients.
Set up server-to-server communications between Library clients and Library Manager.
Configure the library on the Tivoli Storage Manager server that is going to act as the library manager.
Configure the library on the Tivoli Storage Manager servers that are going to act as the library clients.
In this example I have taken 2 TSM Servers (PROD & DEV) where PROD acts as Library Manager and DEV acts
as Library client. You should make sure that Library manager is having same or higher version compared to all
the library clients.
On PROD Server
Now we have to define all the library clients as servers in Library manager. In our case we
have only one library client.
define server DEV serverpassword=PASSWORD hladdress=192.168.0.243 lladdress=1864
crossdefine=yes
1. To configure any library to a TSM server, you have to follow these prerequisites.
On each server system that will access the library and drives, install and configure the
appropriate device drivers for the devices.
Determine the device names that are needed to define the devices to Tivoli Storage Manager
2. Now, configure the library on a TSM server which acts as a Library Manager. In our case PROD
Server is our desired library manager.
Define all the device classes that are associated with the shared library.
Check in the library inventory. Check in volumes that are already labeled:
Define required storage pools for the shared library with a maximum number of scratch
volumes.
Define the shared library named TSMLIB, and identify the library manager server's name as
the primary library manager.
Define a path from the library client server to each drive that the library client server will be allowed to
access. The device name should reflect the way the library client system sees the device. it is best
practice for any library sharing setup to have all drive path definitions created for the library manager
also created for each library client.
You have to do this step similarly for all the library clients
Define all the device classes that are associated with the shared library.
Define the storage pool, tapepool, which will use the shared library.
1. Create an additional device class on the library manager server. Specify the parameter settings
you want the library client to use.
2. Create a device class on the library client with the same name and device type as the new
device class you created on the library server.
After doing all these steps, you can store the clients data by either of these two procedures.
TSM Library Manager, TSM Library Clients and Storage Agent Compatibilities
TSM Server (Library Manager) Versions TSM Library Clients and Storage Agent Versions
6.3 6.3, 6.2, 6.1 and 5.5 *
6.2 6.2, 6.1 and 5.5
6.1 6.1 and 5.5
5.5 5.5
* = Tivoli Storage Manager 5.5 Storage Agent and Library Client will be supported with Tivoli Storage
Manager 6.3.x servers during the upgrade of Tivoli Storage Manager 5.5 servers to Tivoli Storage Manager
6.3.x.
Virtual Tape Library (VTL) configuration in Tivoli Storage
Manager TSM
A Virtual Tape Library or VTL, is an backup solution that combines traditional tape backup methodology with
low-cost disk technology to create an optimized backup and recovery solution. It is an intelligent disk-based
library that emulates traditional tape devices and tape formats. Acting like a tape library with the performance
of modern disk drives, data is deposited onto disk drives just as it would onto a tape library, only faster. Virtual
tape backup solutions can be used as a secondary backup stage on the way to tape, or as their own standalone
tape library solution. A VTL generally consists of a Virtual Tape appliance or server, and software which
emulates traditional tape devices and formats.
Defining a VTL to the Tivoli Storage Manager server can help improve performance because the server handles
mount point processing for VTLs differently than real tape libraries. The physical limitations for real tape
hardware are not applicable to a VTL, affording options for better scalability. You can use a VTL for any virtual
tape library when the following conditions are true:
There is no mixed media involved in the VTL. Only one type and generation of drive and media is
emulated in the library.
Every server and storage agent with access to the VTL has paths that are defined for all drives in
the library.
If either of these conditions are not met, any mount performance advantage from defining a VTL library to the
Tivoli Storage Manager server can be reduced or negated.
VTLs are compatible with earlier versions of both library clients and storage agents. The library client or
storage agent is not affected by the type of library that is used for storage. If mixed media and path
conditions are true for a SCSI library, it can be defined or updated as LIBTYPE=VTL.
You have to define a virtual tape library (VTL) to TSM Server to take advantage of mount performance and
scalability advantages. VTLs are identified by using the DEFINE LIBRARY command and
specifying LIBTYPE=VTL. Because a VTL library functionally interacts with the server in the same way that
a SCSI library does, it is possible to use the UPDATE LIBRARY command to change the library type of a
SCSI library that is already defined. You do not have to redefine the library.
To help prevent out-of-space errors, ensure that any SCSI library that you update to LIBTYPE=VTL is
updated with the RELABELSCRATCH parameter set to YES. The RELABELSCRATCH option enables the
server to overwrite the label for any volume that is deleted and to return the volume to scratch status in the
library. The RELABELSCRATCH parameter defaults to YES for any library defined as a VTL.
This sets up the new VTL library and enables the RELABELSCRATCH option to relabel volumes that have
been deleted and returned to scratch status.
You can only issue this command when the library being updated is defined with LIBTYPE=SCSI.
How to revert a real tape library from the VTL library type
If you define a SCSI tape library as a VTL and want to change it back to the SCSI library type, update the
library by issuing the UPDATE LIBRARY command:
IBM Tivoli Storage Manager for Storage Area Networks is a feature of Tivoli Storage Manager that enables
LAN-free client data movement. This feature allows the client system to directly write data to, or read data
from, storage devices attached to a storage area network (SAN), instead of passing or receiving the
information over the network. Data movement is thereby off-loaded from the LAN and from the Tivoli
Storage Manager server, making network bandwidth available for other uses. For instance, using the SAN
for client data movement decreases the load on the Tivoli Storage Manager server and allows it to support
a greater number of concurrent client connections. .
The storage agent can support several clients while installed on only one of the clients. You can install the
storage agent on a client machine that shares storage resources with the Tivoli Storage Manager server or
on a client machine that does not share storage resources but is connected to a client machine that does
share storage resources with the Tivoli Storage Manager server. You must specify the
LANFREECOMMMETHOD option in the client system options file (dsm.sys) to allow the client machine
(that shares storage resources) to communicate with the storage agent. A Tivoli Storage Manager server,
acting as a library manager, controls the storage devices. This server may be the server working in
conjunction with the storage agent or another Tivoli Storage Manager server in the enterprise. The Tivoli
Storage Manager server keeps track of the metadata that the client has stored. The metadata, such as
policy information and file name and size, is passed over the LAN connection between the storage agent
and server.
The storage agent communicates with the server to obtain and store database information and to
coordinate device and volume access. The server and client coordinate and negotiate data access through
the SAN. The client will use the storage agent for operations where appropriate. For example, if a SAN path
is defined, the client (by means of the storage agent) transfers data on that path. If a failure occurs on the
SAN path, failover occurs and the client uses its LAN connection to the Tivoli Storage Manager server and
moves the client data over the LAN.
There are cases when the storage agent can send the data directly to the server using the LAN control
paths between the storage agent and the server. An example of this would be a LAN-free storage pool that
is updated to read-only after the client connects to the server and obtains its initial policy information. The
storage agent, instead of failing the operation, will send the data to the server, and, providing that the
storage hierarchy is configured so that the next storage pool destination is available, the server will handle
the operation. You can also prevent data from transferring over the LAN by specifying the Tivoli Storage
Manager server parameters DATAREADPATH and DATAWRITEPATH with the REGISTER NODE or
UPDATE NODE commands for the desired node. Tivoli Storage Manager supports SAN-attached device
sharing in one of the following ways.
Planning to Install
You can set up IBM Tivoli Storage Manager for Storage Area Networks in a number of environments.
Planning the system configuration provides a smooth transition through system setup and into production.
As part of your planning, you need to identify the following:
The library used for the LAN-free enabled device. If the library is a Tivoli Storage Manager shared library,
you must identify the Tivoli Storage Manager server that is the library manager. If the library is an externally
managed library using StorageTek ACSLS, you must identify the control point
Part 2:
To install and configure TSM storage agent for lanfree backup operations you should first check the
compatibility of TSM server, TSM baclient and TSM storage agent . IF you use tivoli data protection (tdp) to
backup your database and mail servers in your environment, you should also check the version
compatibility between them. For version compatibility to your environment check the IBM information center
and download the software packages appropriately. To use LAN-free operations, you need a Tivoli Storage
Manager server license. If you use large tape libraries, you need a Tivoli Storage Manager Extended
Edition license.
1) Preparing for install by knowing the Requirements & Limitations of TSM Storage
Agents
1) By installing TSM storage agent on your systems you can backup the data lanfree i.e through fibre
channel cables which reduces lots of pressure on LAN. These fibre channel cables should be used to
connect TSM server, tape library and client computers in order to form Storage Area Networks (SAN). A
Tivoli Storage Manager server, acting as a library manager, controls the storage devices. The storage
agent can send the data directly to the server using the paths between the storage agent and the server.
Only V6.2 or later storage agents can use LAN-free data movement to access storage pools that contain
data that was deduplicated by clients. V6.1 or earlier storage agents cannot use LAN-free data movement
to access these storage pools.
2) Multiple sessions are used for the no-query restore when data for the restore resides on devices with a
LAN-free path and devices with a LAN-only path. Some sessions restore data from the server with a LAN-
only path. The other sessions use the storage agent to restore data over the LAN-free path.
3) The number of sessions used for a restore operation is dependent on the value of the client
RESOURCEUTILIZATION option and the number of server volumes that contain the client data to be
restored. It is also a best practice to define all the available tape drives to all the storage agents, if one fails
another will be used.
4) The storage agent can support several clients while installed on only one of the clients. You can also
install the storage agent on a client system that does not share storage resources with the Tivoli Storage
Manager server, but that is connected to a client system that does share storage resources. The
LANFREECOMMMETHOD option allows a client system that shares storage resources to communicate
with the storage agent. The LANFREECOMMMETHOD option also allows the storage agent to support
several clients while the storage agent is installed on only one of the clients
2) Follow the same procedure which you use to install TSM BA clients and TDP clients. To install storage
agent, go to the directory where the executable packages are located and use either SMITTY tool or use
installp commands. The default path for a storage agents 6.1 or later is /opt/tivoli/tsm/StorageAgent/bin.
5) Configuring dsm.sys and dsm.opt files to enable LANFree on Client Machines
1) You should first edit the client system option file (dsm.sys) to enable LANfree operation to that client. To
do this go to the BA client installation directory and edit/add the following lanfree parameters to the existing
stanzas. If this is the first time you are configuring dsm.sys file, make sure you also add the correct tsm
server details as shown below.
Enablelanfree yes
lanfreecommmethod tcpip
lanfreetcpserveraddress 192.168.100.100 (storageagent/client ip)
lanfreetcpport 1502
2) Now, you have to configure the client option file (dsm.opt) to point to the correct stanza in dsm.sys file.
To do this open the dsm.opt file located in the same directory and add the same tsmserver name which you
added in dsm.sys file.
Servername tsmserv
the dsm.sys file can contain multiple stanzas to connect multiple client nodes in LAN/LANfree operations.
The SERVERNAME option in the dsm.sys file, which is the client system options file, must match the
SERVERNAME option in the dsm.opt file, which is the client user-options file. However, the option is
unrelated to and does not need to match the SERVERNAME option that is defined for the storage agent in
the storage-agent options file, dsmsta.opt
3) If you installed a Data Protection application client, you must also install and configure the Tivoli Storage
Manager client API, verify that the client system meets the prerequisites for the application programming
interface (API) software. The default path for TSM API is /usr/tivoli/tsm/client/api/bin/
4) You should then specify the environment variables before. The Tivoli Storage Manager API uses unique
environment variables to locate files.
DSMI_CONFIG is the fully qualified name for the client user option file.
DSMI_DIR points to the path containing dsm.sys, dsmtca, and the subdirectory en_US.
DSMI_LOG points to the path for the dsierror.log file.
export dsmi_config=/usr/tivoli/tsm/client/api/bin/dsm.opt
export dsmi_dir=/usr/tivoli/tsm/client/api/bin
export dsmi_log=/home/user_a/logdir
5) Then edit an existing stanza or create a stanza in the dsm.sys file to specify the communications options
between the Tivoli Storage Manager API and server as below
servername tsmserv
nodename LANFREETDPNODE
commmethod tcpip
tcpserveraddress 192.168.200.200 (tsm server ip)
tcpport 1500
enablelanfree yes
lanfreecommmethod tcpip
lanfreetcpserveraddress 192.168.100.100 (storageagent ip)
lanfreetcpport 1502
6) The next step is to create symbolic link between dsm.sys files in API directory and BA directory. This
way they both uses the same server option settings. To do this run
ln -s /usr/tivoli/tsm/client/ba/bin/dsm.sys /usr/tivoli/tsm/client/api/bin/dsm.sys
2) To set up server-to-server communication, issue the following commands on the Tivoli Storage Manager
server.
2) For each client that will use LAN-free data transfer, you must define the client's storage agent to the
server as if the storage agent is another server. Use the same name and password that you specified for
the storage agent when you installed it on the client system.
SSL option is introduced in TSM Storageagent from version 6.3. This parameter specifies that SSL
communication is used. If you specify SSL as the communication method, you must import SSL certificates
from the server to the storage agent, and from the storage agent to the server. Import SSL certificates
before you start the storage agent or the server.
3) If the library to be used for LAN-free data movement is a Tivoli Storage Manager shared library and the
data manager server is a library client, then you must define the storage agent to the library manager as
well as the library client. The storage agent needs to be able to contact the library manager directly when
making mount requests. If the storage agent is only defined to the library client, it will attempt to use
information from the library client to define itself to the library manager. If the storage agent is unable to
define itself to the library manager, then you must define the storage agent manually using the DEFINE
SERVER command issued from the library manager. To verify that the storage agent is defined to the
library manager, issue the following command from the library manager server
4) the next step is to define drives and paths to the storage agent from tape library. Paths allow a client, by
means of a storage agent, access to the library drives that are available to the Tivoli Storage Manager
server. Path-definition requirements depend on the type of device that you are using.
5) You should obtain the names of your tape or disk devices. If you are configuring tape devices, review the
device names. The name of a tape device as known to the server will probably not match the name of the
same tape device as known to the storage agent If your tape library is in shared mode and multiple TSM
servers are connected to single library then you must define paths on the library manager for the storage
agent to each drive that the storage agent will access. In addition, you must define a path for the library
manager to each drive so that the storage agent can use the drive. Define paths by using the following
example command. It is always a good practice to define all the paths available to storage agent. Suppose
if your tape library has 10 drives, define 10 drive paths to storage agent and then to library manager also.
Important: For the same tape device, the device name as known to the server will probably not match the
device name as known to the storage agent. Failures can occur if incorrect device information is provided.
DEVCONFIG devconfig.out
You should use the same server name and passwords which you used while defining server to server
communications. The HLADDRESS option must match the TCPSERVERADDRESS option that is in the
dsm.sys file on the Tivoli Storage Manager client. The SERVERNAME option in the dsm.sys file, which is
the client system options file, must match the SERVERNAME option in the dsm.opt file, which is the client
user-options file. By running the above command it generates the following output in the storage agent
device configuration file
set staname storagnt set stapassword xxxxxxx set stakeydbpw xxxxxxxset stahladdress
agent.example.comdefine server tsmsrver serverpassword=xxxxxxxxxxx hladdress=tsmsrver.example.com
lladdress=1502
The passwords are encrypted in the file. The command also generates the following line in the dsmsta.opt
file
SERVERNAME tsmsrver
1) Issue the VALIDATE LANFREE command to determine which destinations for your node are capable of
LAN-free data movement. For those nodes that are not capable of LAN-free data movement, this command
provides an explanation as to why they are not capable. You can use this information to correct your
configuration before proceeding to the next step.
Now run a backup operation from the client. Ensure the following if you receive a message saying that the
backup has failed:
The Tivoli Storage Manager server is running. If the Tivoli Storage Manager server is not running,
the storage agent will not start.
The client, storage agent, and server are communicating with each other as expected.
The output of this command also provides explanations about destinations that are not LAN-free capable.
Use this information to correct your configuration before proceeding
ANR0415I Session session number proxied by storage agent name for node your node name
This message confirms that LAN-free data movement has occurred.
2) You can also view the backup report issued when backup processing completes. When LAN-free data
movement has occurred, the number of "LAN-Free Bytes Transferred" is greater than zero.
3) Monitor the QUERY SESSION output against the node that is running the LAN-free backup. Review the
Bytes Sent and Bytes Received. You can perform this action by using a Tivoli Storage Manager
administrative command-line client to login to the Tivoli Storage Manager server and storage agent to verify
that the proper sessions have been established. When LAN-free data movement is occurring, a QUERY
SESSION on the storage agent should show bytes received (displayed as Bytes Recvd) for the node
increasing to the total amount of data being backed up. The QUERY SESSION on the Tivoli Storage
Manager server should show a very small number of bytes of metadata received for the same node. If the
node's session exhibits this behavior, the data movement is LAN-free.
4) You can also run the Q SESSION command by using Storagent as below
storagentname: q session
Collocation
The server can keep each client's files on a minimal number of volumes within a storage pool. Because
client files are consolidated, restoring collocated files requires fewer media mounts. However, backing up
files from different clients requires more mounts.
Reclamation
Files on sequential access volumes may expire, move, or be deleted. The reclamation process
consolidates the active, unexpired data on many volumes onto fewer volumes. The original volumes can
then be reused for new data, making more efficient use of media.
Client backup, archive, and space-managed data in primary storage pools can be backed up to copy
storage pools for disaster recovery purposes. As client data is written to the primary storage pools, it can
also be simultaneously written to copy storage pools.
The active versions of client backup data can be copied to active-data pools. Active-data pools provide a
number of benefits. For example, if the device type associated with an active-data pool is sequential-
access disk (FILE), you can eliminate the need for disk staging pools. Restoring client data is faster
because FILE volumes are not physically mounted, and the server does not need to position past inactive
files that do not need to be restored. An active-data pool that uses removable media, such as tape or
optical, lets you reduce the number of volumes for onsite and offsite storage. If you vault data electronically
to a remote location, a SERVER-type active-data pool lets you save bandwidth by copying and restoring
only active data. As backup client data is written to primary storage pools, the active versions can be
simultaneously written to active-data pools.
Caching
When the server migrates files from disk storage pools, duplicate copies of the files can remain in cache
(disk storage) for faster retrieval. Cached files are deleted only when space is needed. However, client
backup operations that use the disk storage pool may have poorer performance.
StoragePool Hierarchy
You can establish a hierarchy of storage pools. The hierarchy can be based on the speed or the cost of the
devices associated with the pools. Tivoli Storage Manager migrates client files through this hierarchy to
ensure the most efficient use of a server's storage devices.
You manage storage volumes by defining, updating, and deleting volumes, and by monitoring the use of
server storage. You can also move files within and across storage pools to optimize the use of server
storage.
How to migrate data from tape to tape in Tivoli Storage
Manager TSM
IBM Tivoli Storage Manager (TSM) supports both Disk-Tape Migration and Tape-Tape Migration. The same
process which we normally use for migrating data from Disk to tape can also be used for Tape to Tape
migration. You can set up migration thresholds for sequential-access storage pools. Migrating data from
one sequential-access storage pool to another might be appropriate in some cases, for example, when you
install a tape drive that uses a different type of tape and want to move data to that tape. A tape-to-tape
migration has limited benefits compared to disk-to-tape migration, and requires at least two tape drives.
To control the migration process, set migration thresholds and migration delays for each storage pool using
the DEFINE STGPOOL and UPDATE STGPOOL commands. You can also specify multiple concurrent
migration processes to better use your available tape drives or FILE volumes. Using the MIGRATE
STGPOOL command, you can control the duration of the migration process and whether reclamation is
attempted prior to migration.
The server migrates files by volume from sequential-access storage pools. Volumes that exceed the
reclamation threshold are migrated first. Files in the least frequently referenced volumes are migrated next.
Before files are migrated, the server checks the migration delay for the storage pool.
For tape and optical storage pools, the server begins the migration process when the ratio of volumes
containing data to the total number of volumes in the storage pool, including scratch volumes, reaches the
high migration threshold. For sequential-access disk (FILE) storage pools, the server starts the migration
process when the ratio of data in a storage pool to the pool's total estimated data capacity reaches the high
migration threshold. The calculation of data capacity includes the capacity of all the scratch volumes
specified for the pool.
When migrating files by volume from sequential-access storage pools, including sequential-access disk
storage pools associated with a FILE device class, the server performs the following procedure:
The server first reclaims volumes that have exceeded the reclamation threshold. Reclamation is a
server process of consolidating files from several volumes onto one volume.
After reclamation processing, the server compares the space used in the storage pool to the low
migration threshold.
If the space used is now below the low migration threshold, the server stops processing. If the
space used is still above the low migration threshold, the server determines which volume is the
least recently referenced volume.
If the amount of time a file has been in the storage pool exceeds the amount of time specified as
the migration delay for the storage pool, the file is eligible for migration. The server selects the
volume for migration only when all files on the volume are eligible for migration.
The server repeats steps 3 and 4 until the storage pool reaches the low migration threshold.
Because migration delay can prevent volumes from being migrated, the server can migrate files from all
eligible volumes but still find that the storage pool is above the low migration threshold. If you set migration
delay for a pool, you need to decide what is more important: either ensuring that files stay in the storage
pool for as long as the migration delay, or ensuring there is enough space in the storage pool for new files.
For each storage pool that has a migration delay set, you can choose what happens as the server tries to
move enough files out of the storage pool to reach the low migration threshold. If the server cannot reach
the low migration threshold by migrating only volumes that meet the migration delay requirement, you can
choose one of the following:
Allow the server to migrate volumes from the storage pool even if they do not meet the migration
delay criteria (MIGCONTINUE=YES). This is the default. Allowing migration to continue ensures
that space is made available in the storage pool for new files that need to be stored there.
Have the server stop migration without reaching the low migration threshold (MIGCONTINUE=NO).
Stopping migration ensures that volumes are not migrated for the time you specified with the
migration delay. The administrator must ensure that there is always enough space available in the
storage pool to hold the data for the required number of days.
If you are planning to use migration for sequential-access storage pools, you need to consider a number of
factors, including the time required to mount tapes into drives and whether collocation is enabled.
4. The time required to mount media, such as tape volumes, into drives
If you decide to migrate data from one sequential-access storage pool to another, ensure that:
Two drives (mount points) are available, one in each storage pool.
The access mode for the next storage pool in the storage hierarchy is set to read/write.
Collocation is set the same in both storage pools. For example, if collocation is set to NODE in the
first storage pool, then collocation should be set to NODE in the next storage pool.
If you want to limit migration from a sequential-access storage pool to another storage pool, set the
high-migration threshold to a high percentage, such as 95%.
There is no straightforward way to selectively migrate data for a specific node from one sequential storage
pool to another. You can use the MOVE NODEDATA command to move file spaces for a node from one
storage pool to another.
Advantages and Disadvantages of using cache in Tivoli Storage
Manager TSM disk storage pools
IBM Tivoli Storage Manager has a feature of caching the data in the disk storage pool even after the data
has been migrated to next storagepool. Using cache in the TSM environment disk storage pools has both
advantages and disadvantages.
What is chache ?
When cache is enabled, the migration process leaves behind duplicate copies of files after the server
migrates these files to the next storage pool in the storage hierarchy. Using cache can improve the speed
with which the server retrieves some files. Consider enabling cache for space-managed files that are
frequently accessed by clients. If space is needed to store new data in the disk storage pool, cached files
are erased and the space they occupied is used for the new data.
For the cache enable storage pools, PCT_UTILIZED is the combination of both cache data and original
client data. For the cache disabled storage pools, PCT_UTILIZED reflects only the original client data.
For example, assume that two files, File A and File B, are cached files that are the same size. If File A was
last retrieved on 05/16/08 and File B was last retrieved on 06/19/08, then File A is deleted to reclaim space
first.
If you do not want the server to update the retrieval date for files when a client restores or retrieves the file,
specify the server option NORETRIEVEDATE in the server options file. If you specify this option, the server
removes copies of files in cache regardless how recently the files were retrieved.
Using cache can increase the time required for client backup operations to complete. Performance
is affected because, as part of the backup operation, the server must erase cached files to make
room for storing new files. The effect can be severe when the server is storing a very large file and
must erase cached files. For the best performance for client backup operations to disk storage
pools, do not use cache.
Using cache can require more space for the server database. When you use cache, more database
space is needed because the server has to keep track of both the cached copy of the file and the
new copy in the next storage pool.
If you want to use caching, you cannot also enable shredding for that disk storage pool.
When cache is disabled and migration occurs, the server migrates the files to the next storage pool
and erases the files from the disk storage pool. By default, the system disables caching for each
disk storage pool because of the potential effects of cache on backup performance.
If you leave cache disabled, consider higher migration thresholds for the disk storage pool. A
higher migration threshold keeps files on disk longer because migration occurs less frequently.
If fast restores of active client data is your objective, you can also use active-data pools, which are
storage pools containing only active versions of client backup data.
Access Modes and Status modes of Storage Pool Volumes in
IBM Tivoli Storage Manager TSM
In Tivoli Storage Manager server access to a volume in a storage pool is determined by the access mode
assigned to that volume. You can manually change the access mode of a volume, or the server can change
the access mode based on what happens when it tries to access a volume.
For example, if the server cannot write to a volume having read/write access mode, the server
automatically changes the access mode to read-only.
Read/write
Allows files to be read from or written to a volume in the storage pool. If the server cannot write to a
read/write access volume, the server automatically changes the access mode to read-only. If a
scratch volume that is empty and has an access mode of off-site is updated so that the access
mode is read/write, the volume is deleted from the database.
Read-only
Allows files to be read from but not written to a disk or tape volume. If a scratch volume that is
empty and has an access mode of off-site is updated so that the access mode is read-only, the
volume is deleted from the database.
Unavailable
Specifies that the volume is not available for any type of access by the server. You must vary offline
a random-access volume before you can change its access mode to unavailable. To vary a volume
offline, use the VARY command. If a scratch volume that is empty and has an access mode of off-
site is updated so that the access mode is unavailable, the volume is deleted from the database.
Destroyed
Specifies that a primary storage pool volume has been permanently damaged. Neither users nor
system processes (like migration) can access files stored on the volume.
This access mode is used to indicate an entire volume that should be restored using the RESTORE
STGPOOL or RESTORE VOLUME command. After all files on a destroyed volume are restored to
other volumes, the destroyed volume is automatically deleted from the database.
Only volumes in primary storage pools can be updated to an access mode of destroyed. You must
vary offline a random-access volume before you can change its access mode to destroyed. To vary
a volume offline, use the VARY command. Once you update a random-access storage pool volume
to destroyed, you cannot vary the volume online without first changing the access mode.
If you update a sequential-access storage pool volume to destroyed, the server does not attempt to
mount the volume. If a volume contains no files and the UPDATE VOLUME command is used to
change the access mode to destroyed, the volume is deleted from the database.
Offsite
Specifies that a copy storage pool volume or active-data pool volume is at an off-site location and
therefore cannot be mounted. Use this mode to help you track volumes that are off-site. The server
treats off-site volumes differently, as follows:
You can only update volumes in a copy storage pool or an active-data pool to off-site access mode.
Volumes that have the device type of SERVER (volumes that are actually archived objects stored
on another Tivoli Storage Manager server) cannot have an access mode of off-site.
ONline
Display random access volumes that are available to the server.
OFfline
Display random access volumes that are not available to the server.
EMPty
Display sequential access volumes that have no data.
PENding
Display volumes with a status of PENDING. These could be sequential-access volumes from which all files
have been deleted, but for which the time specified by the REUSEDELAY parameter on the DEFINE
STGPOOL command has not elapsed. These volumes could also be random-access disk volumes that
were deleted, but that still contain discarded data that is waiting to be shredded. After the data is shredded,
the volume will be physically deleted.
FILling
Display sequential access volumes that the server has written to but has not yet filled to capacity.
FULl
Display sequential access volumes that the server has filled.
Examples
To check the Access mode and Status of a particular volume, run this below command
To update the Access mode and Status of a particular volume, run this below command
>>-UPDate Volume-------volume_name------------------------------>
>--+-------------------------------+---------------------------->
'-ACCess--=--+-READWrite------+-'
+-READOnly-------+
+-UNAVailable----+
| (2) |
+-DEStroyed------+
| (3) |
'-OFfsite--------'
>--+----------------------------+------------------------------->
| (4) |
'-LOcation-------=--location-'
.-WHERESTGpool--=--*---------.
>--+----------------------------+------------------------------->
'-WHERESTGpool--=--pool_name-'
.-WHEREDEVclass--=--*-----------------.
>--+-------------------------------------+---------------------->
'-WHEREDEVclass--=--device_class_name-'
>--+-------------------------------------+---------------------->
| .-,---------------. |
| V | |
'-WHEREACCess--=----+-READWrite---+-+-'
+-READOnly----+
+-UNAVailable-+
+-OFfsite-----+
'-DEStroyed---'
>--+---------------------------------+-------------------------->
| .-,-----------. |
| V | |
'-WHERESTatus--=----+-ONline--+-+-'
+-OFfline-+
+-EMPty---+
+-PENding-+
+-FILling-+
'-FULl----'
.-Preview--=--No------.
>--+---------------------+-------------------------------------><
'-Preview--=--+-No--+-'
'-Yes-'
In a SAN you can share tape drives, optical drives, and libraries that are supported by the Tivoli Storage
Manager server, including most SCSI devices.
When two or more Tivoli Storage Manager servers share a library, one of the TSM servers which is
referred as the Library Manager controls device operations. These operations include mount, dismount,
volume ownership, and library inventory. Other Tivoli Storage Manager servers, which acts as a Library
Clients, use server-to-server communications to contact the library manager and request device service.
Data moves over the SAN between each server and the storage device.
Tivoli Storage Manager allows a client, through a storage agent, to directly back up and restore data to a
tape library on a SAN. LAN-free data movement requires the installation of a storage agent software on the
client machine. TSM Server maintains the database and recovery log, and acts as the library manager to
control device operations. The storage agent on the client handles the data transfer to the device on the
SAN. This implementation frees up bandwidth on the LAN that would otherwise be used for client data
movement.
The following outlines a typical backup scenario for a client that uses LAN-free data movement
The client begins a backup operation. The client and the server exchange policy information over
the LAN to determine the destination of the backed up data. For a client using LAN-free data
movement, the destination is a storage pool that uses a device on the SAN.
Because the destination is on the SAN, the client contacts the storage agent, which will handle the
data transfer. The storage agent sends a request for a volume mount to the server.
The server contacts the storage device and, in the case of a tape library, mounts the appropriate
media.
The server notifies the client of the location of the mounted media.
The client, through the storage agent, writes the backup data directly to the device over the SAN.
The storage agent sends file attribute information to the server, and the server stores the
information in its database.
If a failure occurs on the SAN path, failover occurs. The client uses its LAN connection to the Tivoli Storage
Manager server and moves the client data over the LAN.
Tivoli Storage Manager provides two basic types of configurations that use NDMP for backing up and
managing NAS file servers.
In one type of configuration, Tivoli Storage Manager uses NDMP to back up a NAS file server to a
library device directly attached to the NAS file server. The NAS file server, which can be distant
from the Tivoli Storage Manager server, transfers backup data directly to a drive in a SCSI-attached
tape library. Data is stored in special, NDMP-formatted storage pools, which can be backed up to
storage media that can be moved offsite for protection in case of an on-site disaster.
In the other type of NDMP-based configuration, Tivoli Storage Manager uses NDMP to back up a
NAS file server to a Tivoli Storage Manager storage-pool hierarchy. With this type of configuration
you can store NAS data directly to disk (either random access or sequential access) and then
migrate the data to tape. Data can also be backed up to storage media that can then be moved
offsite. The advantage of this type of configuration is that it gives all the backend-data management
features associated with a conventional Tivoli Storage Manager storage-pool hierarchy, including
migration and reclamation.
In both types of configurations, Tivoli Storage Manager tracks file-system image backups and has the
capability to perform NDMP file-level restores.
TSM NDMP Backup Procedure
In backup images produced by network data management protocol (NDMP) operations for a NAS file
server, Tivoli Storage Manager creates NAS file-system-level or directory-level image backups. The image
backups are different from traditional Tivoli Storage Manager backups because the NAS file server
transfers the data to the drives in the library or directly to the Tivoli Storage Manager server. NAS file
system image backups can be either full or differential image backups. The first backup of a file system on
a NAS file server is always a full image backup. By default, subsequent backups are differential image
backups containing only data that has changed in the file system since the last full image backup. If a full
image backup does not already exist, a full image backup is performed.
If you restore a differential image, Tivoli Storage Manager automatically restores the full backup image first,
followed by the differential image.
Tivoli Storage Manager provides a way to restore data from backup images produced by NDMP operations.
To assist users in restoring selected files, you can create a table of contents (TOC) of file-level information
for each backup image. Using the Web backup-archive client, users can then browse the TOC and select
the files that they want to restore. If you do not create a TOC, users must be able to specify the name of the
backup image that contains the file to be restored and the fully qualified name of the file.
BACKUP NAS client command, with include.fs.nas specified in the client options file or specified in
the client options set.
The virtual file space name cannot be identical to any file system on the NAS node. If a file system is
created on the NAS device with the same name as a virtual file system, a name conflict will occur on the
Tivoli Storage Manager server when the new file space is backed up.
How to configure Tivoli Storage Manager TSM Tape Library:
Tivoli Storage Manager uses a removable storage media to store the clients backup and archived files.
TSM supports many types of tape libraries & removable media, mostly 90% of all the storage media which
are available in the market. These removable medias should correctly attached and configured with TSM
servers for storing clients backups. Any mismatch configuration would results in failing of client backups.
To use a SCSI library for storage in Tivoli Storage Manager server setup, you shoud follow these below
tasks
1. Set the appropriate SCSI ID for each drive and for the library or medium-changer.
2. Physically attach the devices to the server hardware.
3. Install and configure the appropriate device drivers for the library.
4. Determine the device names that are needed to define the library to Tivoli Storage Manager.
Drives with different device types are supported in a single library if you define a device class for each type
of drive. If you are configuring this way, you must include the specific format for the drive's device type by
using the FORMAT parameter with a value other than DRIVE.
Plan for the device by reviewing your storage requirements and hardware environment.
Attach the device to the server system, and ensure that the appropriate device driver is installed
and configured (Atape device drivers on AIX).
Define libraries, drives, paths, device classes, storage pools, and storage volume objects to Tivoli
Storage Manager by using below commands
Define the Tivoli Storage Manager policy that links client data with media for the device. Define or
update the policy that associates clients with the pool of storage volumes and the device.
As an alternative to creating or modifying a Tivoli Storage Manager policy, you can place the new
storage pool in the storage pool migration hierarchy by updating an already defined storage pool.
UPDATE STGPOOL command
Prepare storage volumes for use by the device. At a minimum, you must label volumes for the
device. For SCSI, 349X, and ACSLS libraries, add the volumes to the device's volume inventory by
checking in the volumes.
Each volume used by a server for any purpose must have a unique name. This applies to volumes
that reside in different libraries, volumes used for storage pools, and volumes used for operations
such as database backup or export.
Register clients to the domain associated with the policy that you defined or updated in the
preceding step.
After you have attached and defined your devices, you can store client data in two ways:
1. Have clients back up data directly to tape. Configuring policy for direct-to-tape backups.
2. Have clients back up data to disk. The data is later migrated to tape.
You can also configure devices using the device configuration wizard in the Administration Center.
How to configure Tivoli Storage Manager (TSM) Tape Library
with single device type drives:
Tivoli Storage Manager supports both single device type drives and multi-device type drives in the same
tape library. However, the configuration steps for these Single & Multi-device drive types is different.In this
post we wil see how to configure a simple single device type drives in a tape libraries.
Define a SCSI library named TSMLIB. The library type is SCSI because the library is a SCSI-
controlled automated library. Enter the following command:
If you have a SCSI library with a barcode reader and you would like to automatically label tapes
before they are checked in, you can set the AUTOLABEL parameter to YES. For example:
Define a path from the server to the library. The DEVICE parameter specifies the device driver's
name for the library, which is the special file name.
Define the drives in the library. Both drives belong to the TSMLIB library.
This example uses the default address for the drive's element address. The server obtains the element
address from the drive itself at the time that the path is defined. The element address is a number that
indicates the physical location of a drive within an automated library. The server needs the element address
to connect the physical location of the drive to the drive's SCSI address. You can have the server obtain the
element address from the drive itself at the time that the path is defined, or you can specify the element
address when you define the drive. Depending on the capabilities of the library, the server may not be able
to automatically detect the element address. In this case you must supply the element address when you
define the drive.
Define a path from the server to each drive. The DEVICE parameter specifies the device driver's
name for the drive, which is the device special file name.
If you did not include the element address when you defined the drive, the server now queries the library to
obtain the default element address for the drive.
Now Classify drives according to type by defining Tivoli Storage Manager Device classes. Use
FORMAT=DRIVE as the recording format only if all the drives associated with the device class are
identical. For example, to classify two drives in the TSMLIB library, use the following command to
define a device class named DLTDEVC
query library
query drive
query path
query devclass
Now you can define a storage pool named DLT_POOL associated with the device class named
DLTDEVC.
Define a SCSI library named MIXEDLIB. The library type is SCSI because the library is a SCSI-
controlled automated library. Use the following command:
Define a path from the server to the library. The DEVICE parameter specifies the device driver's
name for the drive, which is the device special file name.
Both drives belong to the MIXEDLIB library. This example uses the default for the drive's element
address. The server obtains the element address from the drive itself at the time that the path is
defined. The element address is a number that indicates the physical location of a drive within an
automated library. The server needs the element address to connect the physical location of the
drive to the drive's SCSI address. You can have the server obtain the element address from the
drive itself at the time that the path is defined, or you can specify the element address when you
define the drive. Depending on the capabilities of the library, the server may not be able to
automatically detect the element address. In this case you must supply the element address when
you define the drive.
Define a path from the server to each drive. The DEVICE parameter specifies the device driver's
name for the drive, which is the device special file name.
If you did not include the element address when you defined the drive, the server now queries the library to
obtain the element address for the drive.
Classify the drives according to type by defining Tivoli Storage Manager device classes, which
specify the recording formats of the drives.
This is the important step, Do not use the DRIVE format, which is the default. Because the drives
are different types, Tivoli Storage Manager uses the format specification to select a drive. The
results of using the DRIVE format in a mixed media library are unpredictable.
query library
query drive
query path
query devclass
Define storage pools associated with the device classes. For example:
Scratch volumes are empty volumes that are labeled and available for use. If you allow scratch
volumes for the storage pool by specifying a value for the maximum number of scratch volumes, the
server can choose from the scratch volumes available in the library, without further action on your
part. If you do not allow scratch volumes, you must perform the extra step of explicitly defining each
volume to be used in the storage pool.
Collocation is turned off by default. Collocation is a process by which the server attempts to keep all
files belonging to a client node or client file space on a minimal number of volumes. Once clients
begin storing data in a storage pool with collocation off, you cannot easily change the data in the
storage pool so that it is collocated.
What are the different types of tape libraries supported
in Tivoli Storage Manager Environment:
Tape Library is one of the storage objects used in Tivoli Storage Manager for storing and moving
data from one tape to another tapes. A physical library is a collection of one or more drives that
share similar media-mounting requirements. That is, the drive can be mounted by an operator or
by an automated mounting mechanism.Any tape library must be first defined in TSM server with
appropriate commands to use the library.
Shared Libraries
Shared libraries are logical libraries that are represented physically by SCSI, 349X, or ACSLS
libraries. The physical library is controlled by the Tivoli Storage Manager server configured as a
library manager. Tivoli Storage Manager servers using the SHARED library type are library clients
to the library manager server. If you want to use a single library for 2 or more TSM Servers use
this type to define the library.
An automated cartridge system library software (ACSLS) library is a type of external library that is
controlled by Oracle StorageTek ACSLS media-management software. The server can act as a
client application to the ACSLS software to use the drives. The StorageTek software performs the
following functions
The ACSLS software selects an appropriate drive for media-access operations. You do not define
the drives, check in media, or label the volumes in an external library.
In manual libraries, operators mount the volumes in response to mount-request messages issued
by the server. The server sends these messages to the server console and to administrative
clients that were started by using the special MOUNTMODE or CONSOLEMODE parameter.
SCSI libraries
A SCSI library is controlled through a SCSI interface, attached either directly to the server's host
using SCSI cabling or by a storage area network. A robot or other mechanism automatically
handles volume mounts and dismounts. The drives in a SCSI library can be of different types. A
SCSI library can contain drives of mixed technologies, for example LTO Ultrium and DLT drives.
Some examples of this library type are
A virtual tape library (VTL) is a hardware component that can emulate a tape library while using a
disk as the underlying storage hardware. Using a VTL, you can create variable numbers of drives
and volumes because they are only logical entities within the VTL. The ability to create more
drives and volumes increases the capability for parallelism, giving you more simultaneous mounts
and tape I/O. VTLs use SCSI and Fibre Channel interfaces to interact with applications. Because
VTLs emulate tape drives, libraries, and volumes, an application such as Tivoli Storage Manager
cannot distinguish a VTL from real tape hardware unless the library is identified as a VTL.
349X Libraries
A 349X library is a collection of drives in an IBM 3494. Volume mounts and demounts are handled
automatically by the library. A 349X library has one or more library management control points
(LMCP) that the server uses to mount and dismount volumes in a drive. Each LMCP provides an
independent interface to the robot mechanism in the library. The drives in a 3494 library must be
of one type only (either IBM 3490, 3590, or 3592).
External Libraries
The external media manager selects the appropriate drive for media-access operations. You do
not define the drives, check in media, or label the volumes in an external library. An external
library allows flexibility in grouping drives into libraries and storage pools. The library can have
one drive, a collection of drives, or even a part of an automated library.
Zosmedia libraries
A zosmedia library represents a tape or disk storage resource that is attached with a Fibre
Channel connection (FICON) and is managed by Tivoli Storage Manager for z/OS Media.
A zosmedia library does not require drive definitions. Paths are defined for the Tivoli Storage
Manager server and any storage agents that need access to the zosmedia library resource
in of tape volumes to use them in the tape library. All the tape volumes should be labelled and
checked into library with appropriate commands, misuse of these LABEL & CHECKIN commands
will result in losing are the same whether the library contains drives of a single device type, or
drives of multiple device types.
Always ensure that enough labeled volumes in the library are available to the server so that you
do not run out during an operation such as client backup. Label and set aside extra scratch
volumes for any potential recovery operations you might have later.
Each volume used by a server for any purpose must have a unique name. This requirement
applies to all volumes, whether the volumes are used for storage pools, or used for operations
such as database backup or export. The requirement also applies to volumes that reside in
different libraries but that are used by the same server.
>>-LABEl LIBVolume--library_name-------------------------------->
>----+-volume_name----------------------------------------------------+----
>
'-SEARCH--=--+-Yes--| A |--+--LABELSource--=--+-Barcode--------+-'
'-Vollist--| B |-'
.-OVERWRITE--=--No------.
>--+-------------------------+--+-----------------------+------->
'-CHECKIN--=--+-SCRatch-+-' '-OVERWRITE--=--+-No--+-'
'-PRIvate-' '-Yes-'
.-WAITTime--=--60----.
>--+--------------------+--------------------------------------><
'-WAITTime--=--value-'
A (SEARCH=Yes, SEARCH=Bulk)
|--+-VOLRange--=----volume_name1,volume_name2---+---------------|
| .-,-----------. |
| V | |
'-VOLList--=--+---volume_name-+--+-----------'
'-FILE:--file_name-'
B (LABELSource=Vollist)
.-,-----------.
V |
|--VOLList--=--+---volume_name-+--+-----------------------------|
'-FILE:--file_name-'
Where CHECKIN Specifies whether the server checks in the volume. This parameter is optional. The
following are possible values:
SCRatch
Specifies that the server checks in the volumes and adds them to the library's scratch pool. If a volume
has an entry in volume history, you cannot check it in as a scratch volume.
PRIvate
Specifies that the server checks in the volumes and designates them as private. Private volumes are
available only when you request them by name.
If you do not specify a value for this parameter, then the command will only label the volume but will
not check it in. If you do not specify a value for this parameter and you want to check in the volume,
you must issue the CHECKIN LIBVOLUME command.
>>-CHECKIn LIBVolume--library_name------------------------------>
.-SEARCH--=--No-.
>----+-volume_name--+---------------+-+------------------------->
+-SEARCH--=--Yes--+-------+------+
| '-| A |-' |
'-SEARCH--=--Bulk--+-------+-----'
'-| A |-'
.-OWNer--=--""----------.
>--STATus--=--+-PRIvate-+--+-----------------------+------------>
+-SCRatch-+ '-OWNer--=--server_name-'
'-CLEaner-'
.-CHECKLabel--=--Yes---------. .-SWAP--=--No------.
>--+----------------------------+--+------------------+--------->
'-CHECKLabel--=--+-Yes-----+-' '-SWAP--=--+-No--+-'
+-No------+ '-Yes-'
'-Barcode-'
.-WAITTime--=--60----.
>--+--------------------+--+--------------------------+--------><
'-WAITTime--=--value-' '-CLEanings--=----number---'
A (SEARCH=Yes, SEARCH=Bulk)
|--+-VOLRange--=----volume_name1,volume_name2---+---------------|
| .-,-----------. |
| V | |
'-VOLList--=--+---volume_name-+--+-----------'
'-FILE:--file_name-'
Where SEARCH Specifies whether the server searches the library to find volumes that were not
checked in. This parameter is optional. The default is NO. Possible values are:
No
Specifies that only the named volume is checked into the library. For SCSI libraries: The server
issues a request to have the volume inserted into a cartridge slot in the library or, if available, into
an entry port. The cartridge slot or entry port is identified by its element address. For 349X
libraries: The volume could already be in the library, or you could put it into the I/O station when
prompted.
Yes
Specifies that the server searches the library for volumes to be checked in. You can use the
VOLRANGE or VOLLIST parameter to limit the search. When using this parameter, consider the
following restrictions:
If the library is shared between applications, the server could examine a volume required
by another application. For 349X libraries, the server queries the library manager to
determine all volumes that are assigned to the SCRATCH or PRIVATE category and to the
INSERT category.
For SCSI libraries, do not specify both SEARCH=YES and CHECKLABEL=NO in the same
command.
Bulk
specifies that the server searches the library's entry/exit ports for volumes that can be checked in
automatically. This option only applies to SCSI libraries.
Restrictions:
Tape Drives
A drive object represents a drive mechanism within a library that uses removable media. For
devices with multiple drives, including automated libraries, you must define each drive separately
and associate it with a library. Drive definitions can include such information as the element
address for drives in SCSI or virtual tape libraries (VTLs), how often a tape drive is cleaned, and
whether the drive is online. Tivoli Storage Manager drives include tape and optical drives that can
stand alone or that can be part of an automated library. Supported removable media drives also
include removable file devices such as rewritable CDs.
Device class
Each device that is defined to Tivoli Storage Manager is associated with one device class, which
specifies the device type and media management information, such as recording format,
estimated capacity, and labeling prefixes. A device type identifies a device as a member of a
group of devices that share similar media characteristics. Device types include a variety of
removable media types as well as FILE, CENTERA, and SERVER. A device class for a tape or
optical drive must also specify a library.
Disk Devices
Using Tivoli Storage Manager, you can define random-access disk (DISK device type) volumes
using a single command. You can also use space triggers to automatically create preassigned
private volumes when predetermined space-utilization thresholds are exceeded.
Removable Media
Tivoli Storage Manager provides a set of specified removable-media device types, such as 8MM
for 8 mm tape devices, or REMOVABLEFILE for Jaz or DVD-RAM drives. The GENERICTAPE
device type is provided to support certain devices that are not supported by the Tivoli Storage
Manager server.
Ex: define devclass LTOTAPE devtype=lto library=TSMLIB format=ultrium4c
mountlimit=12 mountretention=5
The FILE device type lets you create sequential volumes by creating files on disk storage. To the
server, these files have the characteristics of a tape volume. FILE volumes can also be useful
when transferring data for purposes such as electronic vaulting or for taking advantage of
relatively inexpensive disk storage devices. FILE volumes are a convenient way to use sequential-
access disk storage for the following reasons:
You do not need to explicitly define scratch volumes. The server can automatically acquire
and define scratch FILE volumes as needed.
You can create and format FILE volumes using a single command. The advantage of
private FILE volumes is that they can reduce disk fragmentation and maintenance
overhead.
Using a single device class definition that specifies two or more directories, you can create
large, FILE-type storage pools. Volumes are created in the directories you specify in the
device class definition. For optimal performance, volumes should be associated with file
systems.
The Tivoli Storage Manager server allows concurrent read-access and write-access to a volume
in a storage pool associated with the FILE device type. Concurrent access improves restore
performance by allowing two or more clients to access the same volume at the same time.
Multiple client sessions (archive, retrieve, backup, and restore) or server processes (for example,
storage pool backup) can read the volume concurrently. In addition, one client session or one
server process can write to the volume while it is being read. Unless sharing with storage agents
is specified, the FILE device type does not require you to define library or drive objects. The only
required object is a device class.
The CENTERA device type defines the EMC Centera storage device. It can be used like any
standard storage device from which files can be backed up and archived as needed. The Centera
storage device can also be configured with the Tivoli Storage Manager server to form a
specialized storage system that protects you from inadvertent deletion of mission-critical data
such as e-mails, trade settlements, legal documents, and so on. The CENTERA device class
creates logical sequential volumes for use with Centera storage pools. These volumes share
many of the same characteristics as FILE type volumes. With the CENTERA device type, you are
not required to define library or drive objects. CENTERA volumes are created as needed and end
in the suffix "CNT."
The SERVER device type lets you create volumes for one Tivoli Storage Manager server that
exist as archived files in the storage hierarchy of another server. These virtual volumes have the
characteristics of sequential-access volumes such as tape. No library or drive definition is
required. You can use virtual volumes for the following
Device-sharing between servers. One server is attached to a large tape library device.
Other servers can use that library device indirectly through a SERVER device class.
Data-sharing between servers. By using a SERVER device class to export and import
data, physical media remains at the original location instead having to be transported.
Immediate offsite storage. Storage pools and databases can be backed up without
physically moving media to other locations.
Offsite storage of the disaster recovery manager (DRM) recovery plan file.
Electronic vaulting
If you are mixing different types of drives and media, configure different device classes,
one for each type of media. To specify the exact media type, use the FORMAT parameter
in each of the device class definitions. (Do not specify FORMAT=DRIVE).
For example, if you are mixing Ultrium Generation 1 and Ultrium Generation 2 drives,
specify FORMAT=ULTRIUMC (or ULTRIUM) for the Ultrium Generation 1 device class,
and FORMAT=ULTRIUM2C (or ULTRIUM2) for the Ultrium Generation 2 device class.
Both device classes can point to the same library in which there can be Ultrium Generation
1 and Ultrium Generation 2 drives. The drives will be shared between the two storage
pools. One storage pool will use the first device class and Ultrium Generation 1 media
exclusively. The other storage pool will use the second device class and Ultrium
Generation 2 media exclusively. Because the two storage pools share a single library,
Ultrium Generation 1 media can be mounted on Ultrium Generation 2 drives as they
become available during mount point processing.
There are also exceptions to the rule against mixing generations of LTO Ultrium drives and media.
The Tivoli Storage Manager server support mixtures of the following types
Generation 2
With a cartridge capacity of up to 400 GB (2:1 compression) and up to 200 GB native, Ultrium
format Generation 2 provides data transfer rates of up to 80 MB/second (2:1 compression).
Licenses for Generation 2 became available in April 2002 with products appearing in late 2002.
Generation 3
Featuring capacities of 800 GB (2:1 compression) and up to 400 GB native per cartridge, Ultrium
format Generation 3 provides data transfer rates of up to 160 MB/second (2:1 compression) for
the third generation of the 8-channel version. Generation 3 licenses became available on July 26,
2004 with products appearing in late 2004.
Generation 4
Delivering 1.6TB (2:1 compression) and up to 800 GB native per cartridge, Ultrium format
Generation 4 provides data transfer rates of up to 240 MB/second (2:1 compression), the LTO
Ultrium format generation specification was made available to licensees in late December 2006.
Generation 5
Delivering 3 TB (assuming a 2:1 compression), up to 280 MB/s (assuming a 2:1 compression),
and adds a new partitioning feature and Linerar Tape File System specification to provide
enhanced file control and data management. The LTO Ultrium format generation 5 specifications
were made available to licensees in January 2010.
Generation 6
With capacity of 6.25 TB (assuming a 2.5:1 compression), LTO Ultrium generation 6 provides data
transfer speeds of up to 400 MB/s (assuming a 2.5:1 compression) and continues support of
partitioning to enable functions like LTFS making tape easy to manage, encryption - helping to
secure data, and WORM to address compliance needs.
Generation 7
Capacity: Up to 16 TB (assuming a 2.5:1 compression)
Data transfer speed: up to 788 MB/s (assuming a 2.5:1 compression)
Generation 8
Capacity: Up to 32 TB (assuming a 2.5:1 compression)
Data transfer speed: up to 1,180 MB/s (assuming a 2.5:1 compression)
LTO Ultrium Generation 3 drives can only read Generation 1 media. If you are mixing
Ultrium Generation 1 with Ultrium Generation 3 drives and media in a single library, you
must mark the Generation 1 media as read-only, and all Generation 1 scratch volumes
must be checked out.
LTO Ultrium Generation 4 drives can only read Generation 2 media. If you are mixing
Ultrium Generation 2 with Ultrium Generation 4 drives and media in a single library, you
must mark the Generation 2 media as read-only, and all Generation 2 scratch volumes
must be checked out.
LTO Ultrium Generation 5 drives can only read Generation 3 media. If you are mixing
Ultrium Generation 3 with Ultrium Generation 5 drives and media in a single library, you
must mark the Generation 3 media as read-only, and all Generation 3 scratch volumes
must be checked out.
If your TSM environment has a mixed LTO device type drives then you should carefully decide the
value for the MOUNTLIMIT parameter while defining device classes for these device types. For
example in a mixed media library containing Ultrium Generation 1 and Ultrium Generation 2 drives
and media, Ultrium Generation 1 media can get mounted in Ultrium Generation 2 drives.
Consider the example of a mixed library that consists of the following drives and media
Four LTO Ultrium Generation 1 drives and LTO Ultrium Generation 1 media
Four LTO Ultrium Generation 2 drives and LTO Ultrium Generation 2 media
LTO Ultrium Generation 1 storage pool LTO1POOL based on device class LTO1CLASS
The number of mount points available for use by each storage pool is specified in the device class
using the MOUNTLIMIT parameter.
The MOUNTLIMIT parameter in the LTO2CLASS device class should be set to 4 to match
the number of available drives that can mount only LTO2 media.
The MOUNTLIMIT parameter in the LTO1CLASS device class should be set to a value
higher (5 or possibly 6) than the number of available drives to adjust for the fact that
Ultrium Generation 1 media can be mounted in Ultrium Generation 2 drives.
The optimum value for MOUNTLIMIT will depend on workload and storage pool access
patterns.
Monitor and adjust the MOUNTLIMIT setting to suit changing workloads. If the MOUNTLIMIT for
LTO1POOL is set too high, mount requests for the LTO2POOL might be delayed or fail because
the Ultrium Generation 2 drives have been used to satisfy Ultrium Generation 1 mount requests.
In the worst scenario, too much competition for Ultrium Generation 2 drives might cause mounts
for Generation 2 media to fail with the following message:
If the MOUNTLIMIT for LTO1POOL is not set high enough, mount requests that could potentially
be satisfied LTO Ultrium Generation 2 drives will be delayed.
Some restrictions apply when mixing Ultrium Generation 1 with Ultrium Generation 2 or
Generation 3 drives because of the way in which mount points are allocated. For example,
processes that require multiple mount points (MOVE DATA & BACKUP STGPOOL) that include
both Ultrium Generation 1 and Ultrium Generation 2 volumes might try to reserve Ultrium
Generation 2 drives only, even when one mount can be satisfied by an available Ultrium
Generation 1 drive. These processes will wait until the needed number of mount points can be
satisfied with Ultrium Generation 2 drives.
What are the different types of tape drive encryption
methods and limitations in Tivoli Storage Manager TSM
Drive encryption protects tapes that contain critical or sensitive data (for example, tapes that
contain sensitive financial information). Drive encryption is particularly beneficial for tapes that are
moved from the Tivoli Storage Manager server environment to an off-site location. Tivoli Storage
Manager supports encryption for the following drives
Tivoli Storage Manager supports the three types of drive encryption available with LTO generation
4 drives. These methods are defined through the hardware.
1. Application Method
2. System Method
3. Library Method
Tivoli Storage Manager supports the Application method of encryption with IBM and HP LTO-4
drives. Only IBM LTO-4 supports the System and Library methods. The Library method of
encryption is supported only if your system hardware (for example, IBM 3584) supports it.
Tip: You cannot use drive encryption with write-once, read-many (WORM) media.
The Application method is defined through the hardware. To use the Application method, in which
Tivoli Storage Manager generates and manages encryption keys, set the DRIVEENCRYPTION
parameter to ON. This permits the encryption of data for empty volumes.
If the parameter is set to ON and the hardware is configured for another encryption method,
backup operations will fail. The following simplified example shows the steps you would take to
permit the encryption of data for empty volumes in a storage pool
Define a library:
Define a device class, LTOCLASS, and specify Tivoli Storage Manager as the key
manager:
To disable encryption on new volumes, set the DRIVEENCRYPTION parameter to OFF. The
default value is ALLOW. Drive encryption for empty volumes is permitted if another method of
encryption is enabled.
A library can contain a mixture of drives, some of which support encryption and some that
do not. (For example, a library might contain two LTO-2 drives, two LTO-3 drives, and two
encrypt supported LTO-4 drives.)
You can also mix media in a library using, for example, a mixture of encrypted and non-
encrypted device classes having different tape and drive technologies. However, all LTO-4
drives must support encryption if Tivoli Storage Manager is to use drive encryption.
In addition, all drives within a logical library must use the same method of encryption.
When using Tivoli Storage Manager, do not create an environment in which some drives
use the Application method and some drives use the Library or System methods of
encryption.
To use these scratch volumes in a drive that is not enabled for encryption, either because
the hardware is not capable of encryption or because the encryption method is set to
NONE, you must relabel the volumes.
What is Tivoli Storage Manager Data Deduplication and
different types of TSM deduplication:
Tivoli Storage Manager provides two options for performing data deduplication - Server-side data
deduplication and Client-side data deduplication. Both methods use the same process to identify
redundant data, however the time and location of the deduplication processing is different. In
server-side data deduplication, processing takes place exclusively on the server after the data is
backed up. In client-side data deduplication, the processing is distributed between the server and
the backup-archive client during the backup process.
When restoring or retrieving files, the client node queries for and displays files as it typically does.
If a user selects a file that exists in a deduplicated storage pool, the server reconstructs the file
before restoring it to client machine.
Data Deduplication
In addition to whole files, IBM Tivoli Storage Manager can also deduplicate parts of files that are
common with parts of other files. Data becomes eligible for duplicate identification as volumes in
the storage pool are filled. A volume does not have to be full before duplicate identification starts.
The ability to deduplicate data on either the backup-archive client or the server provides flexibility
in terms of resource utilization, policy management, and security. You can also combine both
client-side and server-side data deduplication in the same production environment. For example,
you can specify certain nodes for client-side data deduplication and certain nodes for server-side
data deduplication. You can store the data for both sets of nodes in the same deduplicated storage
pool.
Backup-archive clients that can deduplicate data can also access data that was deduplicated by
server-side processes. Similarly, data that was deduplicated by client-side processes can be
accessed by the server. Furthermore, duplicate data can be identified across objects regardless of
whether the data deduplication is performed on the client or the server.
Server-side data deduplication is a two-phase process. In the first phase, the server identifies
duplicate data. In the second phase, duplicate data is removed by certain server processes.
Reclaiming volumes in the primary storage pool, copy storage pool, or active-data pool.
Backing up a primary storage pool to a copy storage pool that is also set up for data
deduplication.
Copying active data in the primary storage pool to an active-data pool that is also set up for
data deduplication.
Migrating data from the primary storage pool to another primary storage pool that is also
set up for data deduplication.
Moving data from the primary storage pool to a different primary storage pool that is also
set up for data deduplication.
Moving data within the same copy storage pool or moving data within the same active-data
pool
In client-side data deduplication, the backup-archive client and the server work together to
identify duplicate data.
Subsequent client data-deduplication operations create new extents. Some or all of those extents
might match the extents that were created in previous data-deduplication operations and sent to
the server. Matching extents are not sent to the server again.
When a client backs up or archives a file, the data is written to the primary storage pool
that is specified by the copy group of the management class that is bound to the data. To
deduplicate the client data, the primary storage pool must be a sequential-access disk
(FILE) storage pool that is enabled for data deduplication.
The value of the DEDUPLICATION option on the client must be set to YES. You can set the
DEDUPLICATION option in the client options file, in the preference editor of the TSM
client GUI, or in the client option set on the Tivoli Storage Manager server. Use the
DEFINE CLIENTOPT command to set the DEDUPLICATION option in a client option set.
To prevent the client from overriding the value in the client option set, specify
FORCE=YES.
Client-side data deduplication must be enabled on the server. To enable client-side data
deduplication, use the DEDUPLICATION parameter on the REGISTER NODE or UPDATE
NODE server command. Set the value of the parameter to CLIENTORSERVER.
Ensure files on the client are not excluded from client-side data deduplication processing.
By default, all files are included. You can optionally exclude specific files from client-side
data deduplication with the exclude.dedup client option.
Files on the client must not be encrypted. Encrypted files and files from encrypted file
systems cannot be deduplicated.
Files must be larger than 2 KB and transactions must be below the value that is specified by
the CLIENTDEDUPTXNLIMIT option. Files that are 2 KB or smaller are not deduplicated.
It can reduce the amount of data that is sent over the local area network (LAN).
The processing power that is required to identify duplicate data is offloaded from the server
to client nodes.
Server-side data deduplication is always enabled for deduplication-enabled storage pools.
However, files that are in the deduplication-enabled storage pools and that were
deduplicated by the client, do not require additional processing. The processing power that
is required to remove duplicate data on the server is eliminated, allowing space savings on
the server to occur immediately.
The possible disadvantage of Client side deduplication is that the server does not have whole
copies of client files until you back up the primary storage pools that contain client extents to a
non-deduplicated copy storage pool. (Extents are parts of a file that are created during the data-
deduplication process.) During storage pool backup to a non-deduplicated storage pool, client
extents are reassembled into contiguous files.
By default, primary sequential-access storage pools that are set up for data deduplication must be
backed up to non-deduplicated copy storage pools before they can be reclaimed and before
duplicate data can be removed. The default ensures that the server has copies of whole files at all
times, in either a primary storage pool or a copy storage pool.
What are the daily routine jobs, duties, tasks of Tivoli
Storage Manager Administrator?
As a Tivoli Storage Manager administrator, monitor operations daily to ensure that the Tivoli
Storage Manager system is functioning properly. Daily monitoring tasks focus on examining
server processes, server database, storage pools, and scheduled operations.
You can complete the monitoring tasks by using the command-line interface (CLI), a subset of
these can also be completed by using the Administration Center or IBM® Tivoli Monitoring for
Tivoli Storage Manager.
Examine the database percent utilization, available free space, and free-pages.
Verify that there is enough disk space in the file systems that contain these log files.
o Active log
o Archive log
o Mirror log
o Archive failover log
Verify that the instance directory file system has enough space.
Verify that the database backups completed successfully, and that they are running
frequently enough.
Verify that you have current backup files for device configuration and volume history
information. You can find the file names for the backups by looking in the dsmserv.opt file
for the DEVCONFIG and VOLUMEHISTORY options. Ensure that file systems where the
files are stored have sufficient space.
Check the status of your storage pools to ensure that there is enough space available.
Determine if there are any tape drives offline, or their paths that are offline.
Determine if there are any libraries offline, or their paths that are offline.
Verify the status and settings for disaster recovery manager (DRM).
Check the summary table for scheduled client operations such as backup, restore, archive,
and retrieve.
Check the summary table for scheduled server operations such as migration, reclamation,
and expiration.
TSM Basics and TSM Components Introduction:
What is IBM Tivoli Storage Manager ?
What is Tivoli Storage Manager Suite for Unified Recovery ? - Video Tutorial
How TSM selects and determine the eligibility of client files for backup and archive ?
Full compatibility with hundreds of storage devices, as well as LAN, WAN, and SAN
infrastructures.
Optional customized backup solutions for major groupware, Enterprise Resource Planning
(ERP) applications, and database products.
Tivoli Storage Manager protects an organization’s data against hardware failures and other
errors by storing backup and archive copies of data in offline storage. It can scale to
protect hundreds of computers ranging from laptops (mobile computers) to mainframes,
running a variety of different operating systems, connected via the Internet, WANs, LANs
or SANs.
IBM Tivoli Storage Manager Express is aimed at both the small to medium business with a less
sophisticated IT environment, or the enterprise department that does not need the full suite of
Tivoli Storage Manager features. IBM Tivoli Storage Manager Express provides a subset of Tivoli
Storage Manager features, focusing on backup and recovery for between 5 and 20 client
machines. The features of IBM Tivoli Storage Manager Express are
Automatic configuration
Windows 2003 as the platform for the Tivoli Storage Manager Express server From 5 to 20
client systems.
Tivoli Storage Manager Basic Edition contains a rich set of features and provides the core
functions of backup, recovery, and archive management. The features of IBM Tivoli Storage
Manager basic edition are
The Extended Edition of IBM Tivoli Storage Manager expands on the features and possibilities of
the Basic Edition described in the previous section. Tivoli Storage Manager Extended Edition
adds disaster recovery planning capability for the server, NDMP control for network-attached
storage (NAS) filers, and support for larger capacity tape libraries and more tape drives.
IBM Tivoli Storage Manager TSM Server and client
components:
As data storage management grows more every year, it also becomes more complicated to
manage it. The key to properly managing a complex storage environment is to approach it
strategically. IBM Tivoli Storage Manager is an enterprise-wide storage management application
which provides automated storage management services to workstations, personal computers,
and file servers from various vendors, with a variety of operating systems.
Server Program
The server program provides backup, archive, and space management services to the clients.
You can set up multiple servers in your enterprise network to balance storage, processor, and
network resources.
Administrative interface
The administrative interface allows administrators to control and monitor server activities, define
management policies for clients, and set up schedules to provide services to clients at
regular intervals. Administrative interfaces available include a command-line administrative client
and a web-based interface that is called the Operations Center (TSM V6.4). The Administration
Center interface is also available, but the Operations Center is the preferred monitoring interface.
Tivoli Storage Manager allows you to manage and control multiple servers from a single interface
that runs in a web browser.
The Tivoli Storage Manager server uses a database to track information about server storage,
clients, client data, policy, and schedules. The server uses the recovery log as a scratch pad for
the database, recording information about client and server actions while the actions are being
performed.
Server Storage
The server can write data to hard disk drives, disk arrays and subsystems, stand-alone tape
drives, tape libraries, and other forms of random- and sequential-access storage. The media that
the server uses are grouped into storage pools. The storage devices can be connected directly to
the server, or connected through a local area network (LAN) or a storage area network (SAN).
TSM Client side Components:
A client node can be a workstation, a personal computer, a file server, or even another Tivoli
Storage Manager server. The client node has IBM Tivoli Storage Manager client software installed
and is registered with the server. Network-attached storage (NAS) file servers can also be client
nodes, but when you are using NDMP, they do not have Tivoli Storage Manager client software
installed.
The backup-archive client allows users to maintain backup versions of files, which they can
restore if the original files are lost or damaged. Users can also archive files for long-term storage
and retrieve the archived files when necessary. Users themselves or administrators can register
workstations and file servers as client nodes with a Tivoli Storage Manager server.
The storage agent is an optional component that might also be installed on a system that is a
client node. The storage agent enables LAN-free data movement for client operations and is
The server can use the Network Data Management Protocol (NDMP) to back up and restore file
systems that are stored on a network-attached storage (NAS) file server. The data on the NAS file
server is backed up to a tape library. No Tivoli Storage Manager software needs to be installed on
the NAS file server. A NAS file server can also be backed up over the LAN to a Tivoli Storage
Manager server.
Application client
Application clients allow users to perform online backups of data for applications such as
database programs. After the application program initiates a backup or restore, the application
client acts as the interface to Tivoli Storage Manager. The Tivoli Storage Manager server then
applies its storage management functions to the data. The application client can perform its
functions while application users are working, with minimal disruption.
The following products provide application clients for use with the Tivoli Storage Manager server:
The API allows you to enhance existing applications to use the backup, archive, restore, and
retrieve services that Tivoli Storage Manager provides. Tivoli Storage Manager API clients can
register as client nodes with a Tivoli Storage Manager server.
Tivoli Storage Manager for Space Management provides space management services for
workstations on some platforms. The space management function is essentially a more
automated version of archive. Tivoli Storage Manager for Space Management automatically
migrates files that are less frequently used to server storage, freeing space on the workstation.
The migrated files are also called space-managed files.
With Tivoli Storage Manager, you can use a variety of devices for server storage. Tivoli Storage
Manager can use direct-attached storage devices as well as network-attached storage devices.
Tivoli Storage Manager represents physical storage devices and media with the following
administrator-defined objects.
Library
A library is one or more drives (and possibly robotic devices) with similar media mounting
requirements.
Drive
Data mover
A data mover represents a device that accepts requests from Tivoli Storage Manager to transfer
data on behalf of the server. Data movers transfer data between storage devices.
Path
A path represents how a source accesses a destination. For example, the source can be a server,
and the destination can be a tape drive. A path defines the one-to-one relationship between a
source and a destination. Data may flow from the source to the destination, and back.
Device class
Each device is associated with a device class that specifies the device type and how the device
manages its media.
A storage pool is a named collection of volumes that have the same media type. A storage pool is
associated with a device class. A storage pool volume is associated with a specific storage pool.
For example, an LTO tape storage pool contains only LTO tape volumes
Tivoli Storage Manager (TSM) basic components and
daily operations:
This is the Part 2 of the Tivoli Storage Manager (TSM) Tutorials on TSM Basic Concepts
Introduction. To read Part 1 go to this link Tivoli Storage Manager (TSM) Basic Concepts and
architecture - Part 1
Protecting the Database and Storage Pools explains the functions of the TSM database, active
log, archive log, and storage pools, and how to protect them with backups.
The Tivoli Storage Manager database contains information about registered client nodes,
policies, schedules, and the client data in storage pools. The database is key to the
operation of the server.
The information about the client data, also called metadata, includes the file name, file
size, file owner, management class, copy group, and location of the file in server storage.
The server records changes made to the database (database transactions) in its recovery
log. The recovery log is used to maintain the database in a transactionally consistent state,
and to maintain consistency across server startup operations.
The database does not store client data; it points to the locations of the client files in the
storage pools. The Tivoli Storage Manager database contains information about the Tivoli
Storage Manager server.
The recovery log helps to ensure that a failure such as a system power outage or
application error does not leave the database in an inconsistent state. The recovery log is
essential when you restart the Tivoli Storage Manager or the database, and is required if
you must restore the database. The recovery log consists of these logs:
Active log
The active log files record transactions that are in progress on the server.
Archive log
The archive log contains copies of closed log files that had been in the active log.
Monitor the database, log space, and file systems where the directories are located to
ensure that space is always available. You can monitor the database and recovery log
space whether the server is online or offline. To restore a damaged or lost database you
must have a database backup. You must also have copies of the files that are required to
recover the database and client data. Database backup media and setup files can be
stored offsite for protection
Managing Storage Media describes tasks and concepts associated with media management
including scratch tapes, tape labeling, checkin and checkout, volume access, movement to offsite
storage, expiration, reclamation, and media errors.
Logical storage pools and storage volumes are the principal components in the Tivoli Storage
Manager model of data storage. By manipulating the properties of these objects, you can optimize
the usage of storage devices.
You can arrange storage pools in storage hierarchies, which consist of at least one primary
storage pool to which a client node backs up, archives, or migrates data. Typically, data is stored
initially in a disk storage pool for fast client restores, and then moved to a tape-based storage
pool, which is slower to access but which has greater capacity.
Migration
To maintain free space in primary storage pools, the Tivoli Storage Manager server can
automatically migrate data from one primary pool to the next storage pool in the hierarchy.
When cache is enabled, the migration process leaves behind duplicate copies of files after the
server migrates these files to the next storage pool in the storage hierarchy.
Deduplicating data
Data deduplication is a method for eliminating redundant data in order to reduce the storage that
is required to retain the data.
With collocation enabled, the server attempts to keep files belonging to a group of client nodes, a
single client node, or client file space on a minimal number of sequential-access storage
volumes.
Space on a sequential-access storage volume becomes reclaimable as files expire or are deleted
from the volume.
Monitor your storage pools and volumes to determine space requirements, the status of data
migration from one to storage pool to the next storage pool in the storage hierarchy, and the use
of disk space by cached copies of files that have been migrated to the next storage pool.
You might need to move data from one volume to another volume in the same or a different
storage pool use the MOVE DATA command. The volumes can be on-site volumes or off-site
volumes.
You can move data located in a sequential-access storage pool for one or more nodes, or for a
single node with selected file spaces, using the MOVE NODEDATA command.
Scheduling and Monitoring Daily Operations explains scheduling of daily events on how to monitor
Tivoli Storage Manager.
You can schedule administrative commands to tune server operations and to start
functions that require significant server or system resources during times of low usage.
Automating these operations allows the administrator to ensure that server resources are
available when needed by clients.
Tivoli Storage Manager includes a central scheduling component that allows the automatic
processing of administrative commands during a specific time period when the schedule is
activated. Schedules that are started by the scheduler can run in parallel.
All scheduled events, including their status, are tracked by the server. An event record is
created in the server database whenever processing of a scheduled command is created
or missed.
To help manage schedules for administrative commands, you can request information
about scheduled and completed events. You can request general or exception reporting
queries.
Tivoli Storage Manager provides for automation of common administrative tasks with
server scripts that are stored in the database. Tivoli Storage Manager supports macros on
the administrative client. A macro is a file that contains one or more administrative client
commands.
The following actions describe some of the items that are important to monitor TSM Server daily:
Examine the database percent utilization, available free space, and free-pages.
Verify that there is enough disk space in the file systems that contain Active log, Archive log,
Mirror log, Archive failover log.
Verify that the instance directory file system has enough space.
Verify that the database backups completed successfully, and that they are running frequently
enough.
Determine if there are any tape drives offline, or their paths that are offline.
Determine if there are any libraries offline, or their paths that are offline.
How and when files are backed up and archived to server storage
The number of copies of a file and the length of time copies are kept in server storage
IBM Tivoli Storage Manager provides a standard policy that sets rules to provide a basic amount
of protection for data on workstations. If this standard policy meets your needs, you can begin
using Tivoli Storage Manager immediately. The server process of expiration is one way that the
server enforces policies that you define.
Expiration processing determines when files are no longer needed, that is, when the files are
expired. For example, if you have a policy that requires only four copies of a file be kept, the fifth
and oldest copy is expired. During expiration processing, the server removes entries for expired
files from the database, effectively deleting the files from server storage. You may need more
flexibility in your policies than the standard policy provides. To accommodate individual user's
needs, you may fine tune the STANDARD policy, or create your own policies. Some types of
clients or situations require special policy. For example, you may want to enable clients to restore
backed-up files to a specific point-in-time.
Where the server initially stores backup versions of files and directories
How many backup versions the server keeps of files and directories
How long the server keeps backup versions of files and directories, see Running Expiration
Processing to Delete Expired Files for details
How long the server keeps archived copies of files, see Running Expiration Processing to
Delete Expired Files for details
Management Class
Associates backup and archive groups with files, and specifies if and how client node files are
migrated to storage pools. A management class can contain one backup or archive copy group,
both a backup and archive copy group, or no copy groups. Users can bind (that is, associate) their
files to a management class through the include-exclude list.
Policy Set
Specifies the management classes that are available to groups of users. Policy sets contain one
or more management classes. You must identify one management class as the default
management class. Only one policy set, the ACTIVE policy set, controls policy operations.
Policy Domain
Policy Domain allows an TSM administrator group client nodes by the policies that govern their
files and by the administrators who manage their policies. A policy domain contains one or more
policy sets, but only one policy set (named ACTIVE) can be active at a time. The server uses only
the ACTIVE policy set to manage files for client nodes assigned to a policy domain. You can use
policy domains to
Direct files from different groups of clients to different storage hierarchies based on need
(different file destinations with different storage characteristics)
With default STANDARD policy settings up-to two backup versions of a file on the client’s system
are retained in server storage. The most recent backup version is retained for as long as the
original file is on the client file system. All other versions are retained for up to 30 days after they
become inactive. One backup version of a file that has been deleted from the client’s system is
retained in server storage for 60 days. An archive copy is kept for up to 365 days.
The server manages files based on whether the files are active or inactive. The most current
backup or archived copy of a file is the active version. All other versions are called inactive
versions. An active version of a file becomes inactive when
A user deletes that file on the client node and then runs an incremental backup.
Policy determines how many inactive versions of files the server keeps, and for how long. When
files exceed the criteria, the files expire. Expiration processing can then remove the files from the
server database.
You replace the ACTIVE policy set by activating another policy set. Perform the following steps
Create or modify a policy set so that it contains the policy that you want to implement.
Create a new policy set either by defining a new policy set or by copying a policy set.
Modify an existing policy set (it cannot be the ACTIVE policy set).
You cannot directly modify the ACTIVE policy set. If you want to make a small change to the
ACTIVE policy set, copy the policy to modify it and follow the steps here
Make any changes that you need to make to the management classes, backup copy
groups, and archive copy groups in the new policy set.
Example:
Topics in the below video include the role of the TSM database, storage pool basics, progressive
incremental backup methodology, policy management, and disaster recovery management.
Video1:
http://www.youtube.com/watch?feature=player_embedded&v=Wnw_ObEFLWo
In this below Video the starting and use of the TSM command line and GUI interfaces for Tivoli
Storage Manager 6.3 are described and demonstrated. It demonstrates how to take
Backup/Restore using different TSM interfaces.
Video 2:
http://www.youtube.com/watch?feature=player_embedded&v=DAi9yCpUlSU
What is Tivoli Storage Manager (TSM) Administration
Centre ?
You can monitor or administer Tivoli Storage Manager (TSM) servers in bot command line mode
and GUI modes. The Administration Center is a Web-based graphical user interface for centrally
configuring and managing IBM Tivoli Storage Manager server V5.3 and later, and V6.1, V6.2, and
V6.3.
To administer a Tivoli Storage Manager server using the Administration Center, the Administration
Center must be the same or later version than the servers that you want to administer. For
example, you can use a V6.3 Administration Center to administer a V6.2 server, but you cannot
use a V6.2 Administration Center to administer a V6.3 server.
The Administration Center is a task-oriented interface that replaced the previous administrative
Web interface. The Administration Center provides wizards to help guide you through common
configuration tasks. Using properties notebooks, you can modify settings and perform advanced
management tasks.
To be known as a good TSM administrator, you should be able to do administrative tasks in both
command-line and GUI modes
You need to log in only once to access multiple Tivoli Storage Manager servers from a
single interface.
You can easily monitor the health of your storage environment. Regular status updates are
provided for Scheduled events, the server database and recovery log in server V5.3 and
later.
Storage devices, including information about off-line drives and paths, and mounted
volumes.
You can filter and sort storage objects, such as client nodes and library volumes.
You can use wizards to more easily perform complex tasks, such as creating schedules to
perform client node and administrative operations.
Creating a server maintenance script to perform database and storage pool backup,
migration, expiration, and reclamation.
Configuring storage devices. A comprehensive wizard helps you create a library, add
drives, check in media volumes, and create storage pools.
Configuring V6.1, V6.2, and V6.3 servers on local or remote UNIX systems.
Video:
http://www.youtube.com/watch?feature=player_embedded&v=bR_QR_edT38
What is IBM Tivoli Storage Manager TSM Suite for
Unified Recovery ?
Tivoli Storage Manager Suite for Unified Recovery is a bundle of 10 proven data protection and
recovery software products. It helps organizations of all sizes meet a wide range of data
management challenges for complex, distributed infrastructures. You can deploy the advanced
management tools you need for each of your individual data protection requirements—without
having to worry about individual product licenses.
http://www.youtube.com/watch?feature=player_embedded&v=7ZFwOPeeiyg
Scales to meet the recovery needs of any size organization—by managing up to four
billion data objects on a single server. This solution supports more than 50 operating
system versions and hundreds of server and storage devices.
Manages the entire suite of products from a single user console—you can configure,
manage, upgrade, report and monitor all 10 products from a single administration interface.
http://www.youtube.com/watch?feature=player_embedded&v=c8OhVB_-PIU
Also includes: IBM Tivoli Storage Manager FastBack® for advanced snapshot and near-
instant recovery for Windows and Linux servers; IBM Tivoli Storage Manager FastBack for
Microsoft Exchange and IBM Tivoli Storage Manager FastBack for Bare Machine
Recovery.
Provides online, consistent and centralized data protection for databases, mySAP/SAP R3
environments and email servers running IBM Lotus® Domino® or Microsoft Exchange.
License costs can be reduced through the use of built-in source and target data
deduplication. There is no charge for duplicate copies of the data.
Reduces overall storage costs through policy-based migration of data to less expensive
tiers of storage and automated expiration at the end of the lifecycle.
http://www.youtube.com/watch?feature=player_embedded&v=tXl95HhyFi0
Facilitates a multitude of connections, including Internet, wide area networks (WAN), local
area networks (LAN) and storage area networks (SAN).
Provides superior functionality, performance and reliability because it uses a fully
integrated, enterprise-class IBM DB2 relational database and transaction log to track the
managed data’s metadata. No DB2 database administration skills are required.
Can eliminate the burden of running backups on a virtual machine by using the VMware
vStorage APIs for Data Protection.
Supports the Microsoft Volume Shadow Copy Service to perform full-image snapshots of
virtual machines in Microsoft Hyper-V environments.
Manages backup and restore from across system and application types, locations, service
level requirements and types of failures.
Allows you to configure and set polices for each protected system, monitor and report on
both client and server operations, schedule and push upgrades for Microsoft Windows
client agents and execute backup and restore operations.
What is IBM Tivoli Storage Manager TSM Operations
Center:
The next generation of simplified backup administration dramatically improves scalability and
efficiency. Experience how IBM’s advanced interface for Tivoli Storage Manager enables
consolidation, intuitive problem resolution and integrated team collaboration.
The IBM Tivoli Storage Manager Operations Center is a web-based user interface for monitoring
your storage management environment.
You can use the Operations Center to identify potential issues at a glance, manage alerts, and
access the Tivoli Storage Manager command line.
The Administration Center interface is also available, but the Operations Center is the preferred
monitoring interface.
You can open the Operations Center by using any supported web browser. For a list of supported
web browsers, see Web browser requirements.
Start your browser, and enter https://hostname:secure_port/oc, where hostname represents the
name of the computer where the Operations Center is installed, and secure_port represents the
port number that the Operations Center uses for HTTPS communication on that computer.
http://www.youtube.com/watch?feature=player_embedded&v=YkaJqwTPglM
What is IBM Tivoli Storage Manager TSM
Tivoli Storage Manager is an enterprise level software from IBM Tivoli family where protects you
from the risks of data loss and helps you reduce complexity, manage costs and address
compliance with data retention and availability requirements. Features of Tivoli Storage Manager
are
Improve business continuity by shortening backup and recovery times and maximising
application availability with advanced data recovery management technologies.
Employ data de-duplication and a hierarchy of storage to increase efficiencies and conserve
resources
Help adapt to changes within the IT infrastructure to minimize service disruptions and speed
restorations and backups
Help control storage management costs with ease-of-use features and integration with IBM
network attached storage (NAS) products
Increase visibility into the data protection environment by providing advanced features for
operational monitoring and historical reporting
Create customizable reports in multiple formats such as HTML, Adobe® Portable Document
Formatting (PDF) and comma-separated values (CSV)
Basic components include TSM Database, Recoverylog and Storagepools. TSM Database
contains the metadata of client backups, Recoverylog contains the current DB transaction details
whereas Storagepools are logical group of tape volumes where actual client backups are stored.
1) What is BACKUP?
Backup is nothing but taking a additional copy of data Objects to be used for recovery. Backup
data consist of several versions. Each version at different point in Time but It follows the main
Object version.
2) What is archive?
Archive is nothing but Taking additional copy of file as a separate object in the storage repository
to be retained for specific period of time. But in archive it does not have any versions.
3) What are all different types BACKUP APPLICATIONS available in current trend?
TSM, Symantec Netbackup, Backup Exec, EMC Networker, Hitachi, HP Data1 protector
Incremental Backup, FULL backup, Snapshot backup, Image backup, Group backup, Image with
Differential backup,
TSM stands for Tivoli Storage Manager; It is a Enterprise level backup solution. It was released in
July 29th1993, earlier it is Called as ADSM. When it was taken by IBM It is called as ITSM. It is
mainly used to protect the data from hardware failures and other errors, and it is used in
Enterprise level.
7) Features of TSM?
· Enterprise administration
9) What are the minimum requirements to install TSM SERVER and CLIENT?
Minimum------110mb (Hdd)
RAM -------128mb
Java version---1-4-1
From TSM version 6, hardware and software requirements have changed, please refer IBM
documentation.
In tsm server we will register the node and we will install b/a client software in that System
and we will specify server address, node name , password access generate and few options in
dsm.opt of client machine and we log into that particular client and we will take the backup and
that data goes from the client to server and in server first it checks whether the node is
registered or not and once it is authenticated and server allows the client data in to storage pool
and when it reaches to certain highmig value automatically
Note: while taking backup it starts the two sessions one is used to send the meta data and
second is used to send the actual data.
Database: It is used to store the complete Meta information of the clients, client data, server
information (Meta data:-The information about the data)
Recovery log: It is used to maintain a record of transactional changes in the database .It is of two
modes 1) Normal mode 2) roll forward mode
Storage pool: It is the place where the client data objects are stored
B/A Client: It is client application software, in which system we want to take the backup we will
install in that.
Policy management: It enables the administrator to determine a set of rules how TSM will treat
data. This is set of rules is composed of policy domains, policy sets, management class and copy
groups
Scheduler: It is an automated action used to run the schedule at the specific period of time.
Administrative interfaces: Administration centre, management console, B/A Client, Command line.
It means that while taking backup it only take the new or modified files.
It consists of information about client systems, policymanagement rules, storage pool information,
schedules, locations, sizes
Normal: When the transaction is started in database, then it will start writing in recovery log and
the data is committed to the database.
Roll forward: When the transaction is started in database, then it will start writing in recovery log.
If it is committed, then it will not erase in this mode, until you take database backup.
In this mode, you can recover the database upto its most current state
15) What is Storage Pool and different types of Storage Pools? Explain it?
Storage pool is the place, where the data objects are stored.
Copy: It is used to backup the data from primary storage pools. The copy storage pools can be
stored in offsite location.
Active data: It contains only the latest copies of files (active files).
16) What are different methods available in TSM, to administer the TSM SERVER?
Command line, Admin center, backup/archive GUI, TSM Manager
18) What are the different versions in tsm server and client?
Tsm versions are 5.1, 5.2, 5.3, 5.4, 5.5, 6.1, 6.2, 6.3 latest is 6.4
How to check and monitor Tivoli Storage Manager
(TSM) database health status:
TSM Database (db) is the major component in Tivoli Storage Manager Architecture. It contains the
transaction details of all the client backups and server data transfers. If TSM db is lost or
corrupted it is almost or impossible to recreate the same TSM Server. So, we have to take the db
backup regularly or schedule an db backup which runs automatically without user intervention.
Snapshot: A snapshot database backup is a full database backup that does not interrupt the
current full and incremental backup series. This backup can be stored in offsite for disaster
recovery purposes.
TSM prepares an additional space when predetermined thresholds have been exceeded in the
database.
Maintaining DB Volumes in different directories or LUNs will increase the TSM Server
performance because the I/O resources will be shared between all those directories.
TSM 6.X versions has DB2 database included. Sql queries can be done to search the
queries.
If original database volumes are available. Give only dsmserv restore db command.
Before upgrading the Tivoli Storage Manager server to the new release. Back up critical server
information by using the BACKUP DB, BACKUP DEVCONFIG, and BACKUP VOLHIST
commands
Device configuration information files that you have identified in the dsmserv.opt file, with
the DEVCONFIG option.
Volume history information to files that you have identified in the dsmserv.opt file, with the
VOLUMEHISTORY option.
Save the TSM Server default directory (DEVICECONFIG, VOLHIST, dsmserv.opt and
dsmserv.dsk).
Now install the latest TSM Server software.
Verify that the installation was successful by starting the server.
An upgrade will not normally create a new database, recovery log, and storage pool
volumes. The dsmserv.dsk file points to the locations of the current database and recovery
log volumes.
The installation creates the Database volume (db.dsm), Recovery log volume (log.dsm),
Storage pool volumes (backup.dsm, archive.dsm, and spcmgmt.dsm) volumes in the
same directory:
Specifies, as a percentage of the total number of requests, the number of requests for a database
page that are already in the buffer pool. It should always be greater than 97%.
Query Session
Query Process
Query db f=d
17) What is the relation between volhist file and TSM database?
Volhist file: Use volume history information when you reload the database and audit affected
storage pool volumes. If you cannot start the server, you can use the volume history file to query
the database about these volumes. The volume history includes information about the following
types of volumes:
Database:
· It is used to manage information about client files.
· It consists of information about client systems, policy management rules, storage pool
information, schedules, locations, sizes .
Q db f=d
Related commands:
Backup db
Define dbcopy
Estimate dborgstats
Define dbvolume
Extend db
Reduce db
Reset bufpool
Reset db maxutilization
Query dbvol
22) How to format a dbvol from OS prompt?
24) How to take a scheduled backup which should run for every 8 hrs?
Using this command you can take schuled backup which should run for every 8 hours
Before deleting any db volumes we should make sure that dbvolume is empty. Should move data
from one dbvolume to another dbvolume.
How to check and monitor Tivoli Storage Manager
(TSM) RecoveryLog health status:
The recovery log is critical to the operation of the Tivoli Storage Manager server. If the recovery
log is unusable, the entire server is unavailable. With the recovery log available, and a restored
backup image of the database, you can recover the database to its most current state. To ensure
fast recovery time and high availability of the database, you should always mirror the recovery log.
Mirroring the recovery log requires much less space than mirroring the database. Taking frequent
database backups reduces recovery log storage requirements and the time required to recover
the database.
You can check Q status. There you can find the mode.
You can change the mode using Set log mode roll forward
Using this command you can check the current recovery log information Q log f=d
Using this command you can check the % utilization of recovery log Q log
Using this command you can check the number of volumes Q logvol
The recovery log might appear to be out of space, when it is being pinned by an operation or
combination of operations on the server. A pinned recovery log is where space in the recovery log
cannot be reclaimed and used by current transactions because an existing transaction is
processing slowly or is hung.
If the recovery log is pinned, repeatedly issue the SHOW LOGPINNED command over many
minutes. If this reports the same client session or server processes as pinning the recovery log,
you might take action to cancel or terminate that operation in order to keep the recovery log from
running out of space. To cancel or terminate a session or process that is pinning the recovery log,
issue the SHOW LOGPINNED CANCEL command
9) Recovery log utilization reached 90% and above, what are the actions you have to take
to avoid TSM SERVER Crash?
First issue the SHOW LOGPIN Command, then cancels the pinning session. If it is less than 13 GB,
Then we can extend the log volume.
Using this command, you can find out the recovery log volumes Q logvol f=d
TSM prepares an additional space when predetermined thresholds have been exceeded in the
recovery log.
It will show the which client session or server processes is pinning the recovery log
Q log f=d
Related commands:
Define logcopy
Define logvolume
Extend log
Reduce log
The maximum size of recovery log is 13 GB in TSM 5.5 and 128GB in TSM 6.X versions.
http://www.youtube.com/watch?feature=player_embedded&v=d7XFa8OpE9c
http://www.youtube.com/watch?feature=player_embedded&v=X7a7Sc55q0E
What is Tivoli Storage Manager TSM Policy Management:
This post describes how TSM manages client backup and archives. TSM Policy Management is
the important concept in Tivoli Storage Manager. It defines how client backups are managed in
TSM Server Storage. It contains Policy Domain, Policy Set, Management Class, backup copy
group and archive copy group.
Policy management enables the administrator to determine a set of rules how TSM will treat
data. This is set of rules is composed of policy domains, policy sets, management class and copy
groups.
Policy domain A policy domain is grouping of policy users with one or more policy sets, which
manage data.
Policy set: It is a collection of management class definitions. There can be only one active policy
set and no. of inactive policy sets.
Copygroups: It consists of rules used to govern the data 1) backup copygroup 2) archive
copygroup.
When clients are registered, they are associated with domain. A policy domain is grouping of
policy users with one or more policy sets, which manage data.
It is a collection of management class definitions. There can be only one active policy set and no.
of inactive policy sets
5) What is copygroup?
Destination, VER Exist, VER Delete, RET extra, Ret only, RETver, serialization1111
7) What is version exists?
It is used for how many versions to maintain for a file, if it exits in client system
It specifies how many number of file copies to keep after the file has been deleted
The Serialization attribute determines whether a file can be in use during a backup, the value for
this attribute can be one of the following:
Static: A file or directory must not be modified during a backup. If the object is changed during a
backup attempt, it is not backed up.
Shared static: A file or directory must not be modified during backup. Tivoli Storage Manager
attempts to perform a backup as many as four additional times. If the object is changed during
every backup attempt, it is not backed up.
Dynamic: A file or directory is backed up on the first attempt regardless of whether it changes
during a backup.
14) Explain about archive copy group and its parameters and default values?
Type Archive
Mode Absolute
Active log
Archive log
During the installation process, you specify the directory location, the size of the active log, and
the location of the archive logs. You can also specify the directory location of a log mirror if you
want the additional protection of mirroring the active log. The amount of space for the archive logs
is not limited, which improves the capacity of the server for concurrent operations compared to
previous versions.
The space that you designate for the recovery log is managed automatically by the database
manager program. Space is used as needed, up to the capacity of the defined log directories. You
do not need to create and format volumes for the recovery log.
Ensure that the recovery log has enough space. Monitor the space usage for the recovery log to
prevent problems.
To protect your data, locate the database directories and all the log directories on separate
physical disks.
TSM Recovery log mode
The recovery log mode for the Tivoli® Storage Manager is the roll-forward mode. The recovery log
stores data that is required to back up a restored database to the most recent committed
transaction. You must have the most recent recovery logs to use the roll-forward mode.
Changes to the database are recorded in the recovery log to maintain a consistent database
image. You can restore the server to the latest time possible, by using the active and archive log
files, which are included in database backups.
To help ensure that the required log information is available for restoring the database, you can
specify that the active log is mirrored to another file system location. For the best availability,
locate the active log mirror on a different physical device
Active log
The active log files record transactions that are in progress on the server.
The active log stores all the transactions that have not yet been committed. The active log always
contains the most recent log records. If a failure occurs, the changes that were made but not
committed are rolled back, and all committed transactions, which might not have been physically
written to disk, are reapplied and committed again.
The location and size of the active log are set during initial configuration of a new or upgraded
server. You can also set these values by specifying the ACTIVELOGDIRECTORY and
the ACTIVELOGSIZE parameters of the DSMSERV FORMAT or DSMSERV
LOADFORMAT utilities. Both the location and size can be changed later.
Mirroring the active log can protect the database when a hardware failure occurs on the device
where the active log is stored. Mirroring the active log provides another level of protection in
addition to placing the active log on hardware that has high-availability features. Creating a log
mirror is optional but recommended. Place the active log directory and the log mirror directory on
different physical devices. If you increase the size of the active log, the log mirror size is increased
automatically.
Mirroring the log can affect performance, because of the doubled I/O activity that is required to
maintain the mirror. The additional space that the log mirror requires is another factor to consider.
You can create the log mirror during initial configuration of a new or upgraded server. If you use
the DSMSERV LOADFORMAT utility instead of the wizard to configure the server, specify
the MIRRORLOGDIRECTORYparameter. If the log mirror directory is not created at that time, you
can create it later by specifying theMIRRORLOGDIRECTORY option in the server options file,
dsmserv.opt.
Archive log
The archive log contains copies of closed log files that had been in the active log. The archive log
is not needed for normal processing, but it is typically needed for recovery of the database.
To provide roll-forward recovery of the database to the current point in time, all logs since the last
database backup must be available for the restore operation. The archive log files are included in
database backups and are used for roll-forward recovery of the database to the current point-in-
time. All logs since the last full database backup must be available to the restore function. These
log files are stored in the archive log. The pruning of the archive log files is based on full database
backups. The archive log files that are included in a database backup are automatically pruned
after a full database backup cycle has been completed.
The archive log is not needed during normal processing, but it is typically needed for recovery of
the database. Archived log files are saved until they are included in a full database backup. The
amount of space for the archive log is not limited.
Archive log files are automatically deleted as part of the full backup processes and must not be
deleted manually. Monitor both the active and archive logs. If the active log is close to filling,
check the archive log. If the archive log is full or close to full, run one or more full database
backups.
If the file systems or drives where the archive log directory and the archive failover log directory
are located become full, the archived logs are stored in the active log directory. Those archived
logs are returned to the archive log directory when the space problem is resolved, or when a full
database backup is run.
You set the location of the archive log directory during initial configuration of a new or upgraded
server. You can also specify the ARCHLOGDIRECTORY parameter of the DSMSERV
FORMAT or DSMSERV LOADFORMAT utility. The location of the log can be changed later.
You can specify the location of the failover log directory during initial configuration of a new or
upgraded server. You can also specify its location with
the ARCHFAILOVERLOGDIRECTORY parameter of the DSMSERV FORMATor DSMSERV
LOADFORMAT utility. If it is not created through the utilities, it can be created later by specifying
theARCHFAILOVERLOGDIRECTORY option in the server options file, dsmserv.opt.
When the logs that make up the recovery log are set up carefully, they work together to ensure
that data is not lost.
The active log files contain information about in-progress transactions. This information is needed
to restart the server and database after a disaster. Transactions are stored in the log files of the
active log, and a transaction can span multiple log files.
When all transactions that are part of an active log file complete, that log file is copied from the
active log to the archive log. Transactions continue to be written to the active log files while the
completed active log files are copied to the archive log. If a transaction spans all the active log
files, and the files are filled before the transaction is committed, the Tivoli® Storage
Manager server halts.
When an active log file is full, and there are no active transactions referring to it, the file is copied
to the archive log directory. An active log file cannot be deleted until all transactions in the log file
are either committed or discontinued.
If the archive log is full and there is no failover archive log, the log files remain in the active log. If
the active log then becomes full and there are in-progress transactions, the Tivoli Storage
Manager server halts. If there is an archive failover log, it is used only if the archive log fills. It is
important to monitor the archive log directory to ensure that there is space in the active log.
The Tivoli Storage Manager database manager can move active log files to the failover archive
log. The database manager automatically manages the space that is available to the directories
as database space. The database manager determines when database backups are required and
automatically initiates them.
When the database is backed up, the database manager deletes the archive log files that are no
longer needed for future database backups or restores.
The archive log is included in database backups and is used for roll-forward recovery of the
database. The archive log files that are included in a database backup are automatically pruned
after a full database backup cycle has completed. Therefore, ensure that the archive log has
enough space to store the log files for the database backups.
Making changes to the DDL or database configuration without using Tivoli Storage
Manager interfaces can adversely affect performance, damage or destroy the server database, or
cause data to become permanently lost. Ensure that you do not do any of the following:
Use database tools or interfaces other than those provided or documented by Tivoli
Storage Manager to change configuration settings from those that are set by Tivoli Storage
Manager at installation.
Alter the DB2 environment in other ways. If you use database tools or interfaces other than
those provided or documented by Tivoli Storage Manager, you must treat the server
database as read-only.
The database does not store client data; it points to the locations of the client files in the storage
pools. The Tivoli® Storage Manager database contains information about the Tivoli Storage
Manager server. The database also contains information about the data that is managed by
the Tivoli Storage Manager server. The database includes information about:
Server settings
The database can be distributed across up to 128 directories. It is important that the database is
placed on fast, reliable disks that are configured for random access I/O. Locating each directory
on a different file system provides the best performance because the data is striped across the
directories. Enable read cache for the database, and enable write cache if the disk subsystem
supports it.
The database cannot be mirrored through Tivoli Storage Manager, but it can be mirrored by using
hardware mirroring, such as Redundant Array of Independent Disks (RAID) 5.
If the database is unusable, the Tivoli Storage Manager server is unavailable. You must backup
the database to ensure that data that is managed by the server can be recovered. Encrypt
sensitive data using the Tivoli Storage Manager client or a storage device, unless the storage
media is physically secured. Security can be compromised even if data is not recovered. If a
database is lost and cannot be recovered, it might be difficult or impossible to recover data that is
managed by that server. Fragments of data or complete files might be read from storage pool
volumes that are not encrypted. The database manager manages database volumes, and there is
no need to format them.
Automatic backups
When the server is started for the first time, a full backup begins automatically. When the
server is next started, the database manager automatically backs up the database
according to the following values set by Tivoli Storage Manager:
The active log space used since the last backup, which triggers a full database
backup
The active log utilization ratio, which triggers an incremental database backup
SQL queries
The database makes more sophisticated SQL queries on the data possible. To take
advantage of these functions, you must use SQL to develop new tools and create SQL
statements.
Database audits
Database audits are run automatically, as needed, to ensure consistency. As data is added
to the server database, the database manager checks data constraints and data types.
Online integrity checks can prevent problems for which offline audits had been needed in
earlier releases.
Using TCP/IP to communicate with DB2® can greatly extend the number of concurrent
connections. The TCP/IP connection is part of the default configuration. When the Tivoli Storage
Manager V6.3 server is started for the first time, it inspects the current configuration of the DB2
instance. It then makes any necessary changes to ensure that both IPC and TCP/IP can be used
to communicate with the database manager. Any changes are made only as needed. For
example, if the TCP/IP node exists and has the correct configuration, it is not changed. If the node
was cataloged but has an incorrect IP address or port, it is deleted and replaced by a node having
the correct configuration.
When cataloging the remote database, the Tivoli Storage Manager server generates a unique
alias name based on the name of the local database. By default, a remote database alias of
TSMAL001 is created to go with the default database name of TSMDB1.
Tip: Tivoli Storage Manager disables the TCP/IP connections if it cannot find an alias in the range
TSMAL001-TSMAL999 that is not already in use.
By default, the Tivoli Storage Manager server uses IPC to establish connections for the first two
connection pools, with a maximum of 480 connections for each pool. After the first 960
connections are established, the Tivoli Storage Manager server uses TCP/IP for any additional
connections.
You can use the DBMTCPPORT server option to specify the port on which the TCP/IP
communication driver for the database manager waits for requests for client sessions. The port
number must be reserved for use by the database manager.
If Tivoli Storage Manager cannot connect to the database by using TCP/IP, it issues an error
message and halts. The administrator must determine the cause of the problem and to correct it
before restarting the server. The server verifies that it can connect by using TCP/IP at startup
even if it is configured to initially favor IPC connections over TCP/IP connections.
What are Tivoli Storage Manager (TSM) storage pool
and storage-pool volumes ?
In terms of Tivoli Storage Manager, tapes are referred as storage pool volumes (PRIVATE) if they
are defined to any specific storage pool or volumes (SCRATCH) if they are not defined yet to any
storage pool. In other words, the logical group of same types of tape volumes is known as Storage
pool and volumes in the storage pool are referred as storagep ool volumes.
For DISK device classes, you must define volumes. For other device classes, such as tape and
FILE, you can allow the server to dynamically acquire scratch volumes and define those volumes
as needed
One or more device classes are associated with one library, which can contain multiple drives.
When you define a storage pool, you associate the pool with a device class. Volumes are
associated with pools.
A Private volume is a labeled volume that is in use or owned by an application, and may
contain valid data. You must define each private volume. Alternatively, for storage pools
associated with sequential access disk (FILE) device classes, you can use space triggers
to create private, preassigned volumes when predetermined space-utilization thresholds
have been exceeded. Private FILE volumes are allocated as a whole. The result is less risk
of severe fragmentation than with space dynamically acquired for scratch FILE volumes. A
request to mount a private volume must include the name of that volume. Defined private
volumes do not return to scratch when they become empty.
A Scratch volume is a labeled volume that is empty or contains no valid data and that can
be used to satisfy any request to mount a scratch volume. When data is written to a
scratch volume, its status is changed to private, and it is defined as part of the storage pool
for which the mount request was made. When valid data is moved from the volume and the
volume is reclaimed, the volume returns to scratch status and can be reused by any
storage pool associated with the library.
For each storage pool, you must decide whether to use scratch volumes. If you do not use scratch
volumes, you must define private volumes, or you can use space-triggers if the volume is
assigned to a storage pool with a FILE device type. Tivoli Storage Manager keeps an inventory of
volumes in each automated library it manages and tracks whether the volumes are in scratch or
private status. When a volume mount is requested, Tivoli Storage Manager selects a scratch
volume only if scratch volumes are allowed in the storage pool. The server can choose any
scratch volume that has been checked into the library.
You do not need to allocate volumes to different storage pools associated with the same
automated library. Each storage pool associated with the library can dynamically acquire volumes
from the library's inventory of scratch volumes. Even if only one storage pool is associated with a
library, you do not need to explicitly define all the volumes for the storage pool. The server
automatically adds volumes to and deletes volumes from the storage pool.
A disadvantage of using scratch volumes is that volume usage information, which you can use to
determine when the media has reached its end of life, is deleted when a private volume is
returned to the scratch volume pool.
A library's volume inventory includes only those volumes that have been checked into that
library. This inventory is not necessarily identical to the list of volumes in the storage pools
associated with the library.
1. A volume can be checked into the library but not be in a storage pool (a scratch volume, a
database backup volume, or a backup set volume).
2. A volume can be defined to a storage pool associated with the library (a private volume),
but not checked into the library.
To address this problem, Tivoli Storage Manager (TSM) has the facility of
sending multiple sessions data to a primary Diskpool initially and migrate it to primary
tape storage-pool later when the tape drives are free. This method is called TSM Storage
Hierarchy in terms of Tivoli Storage Manager. The storage pool hierarchy includes only primary
storage pools, not copy storage pools or active-data pools.
You can set up your devices so that the server automatically moves data from one device to
another, or one media type to another. The selection can be based on characteristics such as file
size or storage capacity. A typical implementation might have a disk storage pool with a
subordinate tape storage pool. When a client backs up a file, the server might initially store the file
on disk according to the policy for that file. Later, the server might move the file to tape when the
disk becomes full. This action by the server is called Migration. You can also place a size limit on
files that are stored on disk, so that large files are stored initially on tape instead of on disk.
For example, your fastest devices are disks, but you do not have enough space on these devices
to store all data that needs to be backed up over the long term. You have tape drives, which are
slower to access, but have much greater capacity. You define a hierarchy so that files are initially
stored on the fast disk volumes in one storage pool. This provides clients with quick response to
backup requests and some recall requests. As the disk storage pool becomes full, the server
migrates, or moves, data to volumes in the tape storage pool.
To establish a hierarchy, identify the next storage pool, sometimes called the subordinate storage
pool. The server migrates data to the next storage pool if the original storage pool is full or
unavailable. You can set up a storage pool hierarchy when you first define storage pools. You can
also change the storage pool hierarchy later.
You cannot establish a chain of storage pools that leads to an endless loop. For example, you
cannot define StorageB as the next storage pool for StorageA, and then define StorageA as the
next storage pool for StorageB.
Example:
In the above example, the data will be migrated from DISKPOOL when the storagepool utilization
reaches 85%.
To update the storage-pool definition for BACKUPPOOL to specify that TAPEPOOL is the next
storage pool defined in the storage hierarchy
A storage pool is a collection of storage volumes. A storage volume is the basic unit of storage,
such as allocated space on a disk or a single tape cartridge. The server uses the storage volumes
to store backed-up, archived, or space-managed files.
When a user tries to restore, retrieve, recall, or export file data, the requested file is obtained from
a primary storage pool, if possible. Primary storage pool volumes are always located on-site. A
primary storage pool can use random-access storage (DISK device class) or sequential-access
storage (for example, tape or FILE device classes). TSM storage hierarchy can be configured in
only group of primary pools. You can define a disk pool & tape pool and make diskpool's next
destination as tape pool. This way the client backup first goes to disk pool which will be faster and
then migrate it to tape later.
The server has three default, random-access (DISK) primary storage pools:
ARCHIVEPOOL
In default STANDARD policy, the destination for files that are archived from client nodes
BACKUPPOOL
In default STANDARD policy, the destination for files that are backed up from client nodes
SPACEMGPOOL
For space-managed files that are migrated from Tivoli Storage Manager for Space Management
client nodes (HSM clients).
To prevent a single point of failure, create separate storage pools for backed-up and space-
managed files. This also includes not sharing a storage pool in either storage pool hierarchy.
Consider setting up a separate, random-access disk storage pool to give clients fast access to
their space-managed files.
If you dont give the pooltype parameter it will automatically become primary pool because default
pooltype is PRIMARY
Copy storage pools contain active and inactive versions of data that is backed up from primary
storage pools. Copy storage pools provide a means of recovering from disasters or media failures.
For example, when a client attempts to retrieve a file and the server detects an error in the file
copy in the primary storage pool, the server marks the file as damaged. At the next attempt to
access the file, the server can obtain the file from a copy storage pool.
You can move copy storage pool volumes off-site and still have the server track the volumes.
Moving copy storage pool volumes off-site provides a means of recovering from an on-site
disaster. A copy storage pool can use only sequential-access storage (for example, a tape device
class or FILE device class).
Active-Data Pools:
An active-data pool contains only active versions of client backup data. active-data pools are
useful for fast client restores, reducing the number of on-site or off-site storage volumes, or
reducing bandwidth when copying or restoring files that are vaulted electronically in a remote
location.
Data migrated by hierarchical storage management (HSM) clients and archive data are not
permitted in active-data pools. As updated versions of backup data, continue to be stored in
active-data pools, older versions are deactivated and removed during reclamation processing.
Restoring a primary storage pool from an active-data pool might cause some or all inactive files to
be deleted from the database if the server determines that an inactive file needs to be replaced
but cannot find it in the active-data pool. As a best practice and to protect your inactive data,
therefore, you should create a minimum of two storage pools: one active-data pool, which
contains only active data, and one copy storage pool, which contains both active and inactive
data. You can use the active-data pool volumes to restore critical client node data, and afterward
you can restore the primary storage pools from the copy storage pool volumes. active-data pools
should not be considered for recovery of a primary pool or volume unless the loss of inactive data
is acceptable.
Active-data pools can use any type of sequential-access storage (for example, a tape device class
or FILE device class). However, the precise benefits of an active-data pool depend on the specific
device type associated with the pool. For example, active-data pools associated with a FILE
device class are ideal for fast client restores because FILE volumes do not have to be physically
mounted and because the server does not have to position past inactive files that do not have to
be restored. In addition, client sessions restoring from FILE volumes in an active-data pool can
access the volumes concurrently, which also improves restore
performance.
Active-data pools that use removable media, such as tape or optical, offer similar benefits.
Although tapes need to be mounted, the server does not have to position past inactive files.
However, the primary benefit of using removable media in active-data pools is the reduction of the
number of volumes used for on-site and off-site storage. If you vault data electronically to a
remote location, an active-data pool associated with a SERVER device class lets you save
bandwidth by copying and restoring only active data.
The server will not attempt to retrieve client files from an active-data pool during a point-in-time
restore. Point-in-time restores require both active and inactive file versions. Active-data pools
contain only active file versions. For optimal efficiency during point-in-time restores and to avoid
switching between active-data pools and primary or copy storage pools, the server retrieves both
active and inactive versions from the same storage pool and volumes.
You can issue the COPY ACTIVEDATA command either manually or in an administrative
schedule or maintenance script. Regardless whether you use the COPY ACTIVEDATA command
or the simultaneous-write function, the Tivoli Storage Manager server writes data to an active-data
pool only if the data belongs to a node that is a member of a policy domain that specifies the
active-data pool as the destination for active data.
or
For simultaneously writing active data You have to update domain with
the ACTIVEDESTINATION parameter. All the client nodes assigned to this domain will
simultaneously write data to activedatapool during backup window.
Backup-archive clients can choose to back up their files using full or partial incremental backup. A
full incremental backup ensures that clients' backed-up files are always managed according to
policies. Clients should use full incremental backup whenever possible.
If the amount of time for backup is limited, clients may sometimes need to use partial incremental
backup. A partial incremental backup should complete more quickly and require less memory.
When a client uses partial incremental backup, only files that have changed since the last
incremental backup are backed up. Attributes in the management class that would cause a file to
be backed up when doing a full incremental backup are ignored. For example, unchanged files
are not backed up even when they are assigned to a management class that specifies absolute
mode and the minimum days between backups (frequency) has passed.
The server also does less processing for a partial incremental backup. For example, the server
does not expire files or rebind management classes to files during a partial incremental backup.
If clients must use partial incremental backups, they should periodically perform full incremental
backups to ensure that complete backups are done and backup files are stored according to
policies. For example, clients can do partial incremental backups every night during the week, and
a full incremental backup on the weekend.
Performing full incremental backups is important if clients want the ability to restore files to a
specific time. Only a full incremental backup can detect whether files have been deleted since the
last backup. If full incremental backup is not done often enough, clients who restore to a specific
time may find that many files that had actually been deleted from the workstation get restored. As
a result, a client's file system may run out of space during a restore process. See Setting Policy to
Enable Point-in-Time Restore for Clients for more information.
If files are not excluded and a management class is specified with the INCLUDE option,
IBM Tivoli Storage Manager uses that management class.
If files are not excluded but a management class is not specified with the INCLUDE option,
IBM Tivoli Storage Manager uses the default management class.
If no include-exclude list exists, all files in the client domain are eligible for backup, and
IBM Tivoli Storage Manager uses the default management class.
If there is a backup copy group, the process continues with checking mode and frequency
settings.
If there is no backup copy group, the file is not eligible for backup.
Checks the mode, frequency, and serialization defined in the backup copy group
Mode - Specifies whether the file is backed up only if it has changed since the last backup
(modified) or whenever a backup is requested (absolute).
Frequency - Specifies the minimum number of days that must elapse between backups.
For windows this attribute is ignored during a journal-based backup.
Serialization - Specifies how files are handled if they are modified while being backed up
and what happens if modification occurs.
If the mode is modified and the minimum number of days have elapsed since the file was
last backed up, IBM Tivoli Storage Manager determines if the file has been changed since it
was last backed up
If the file has been changed and the serialization requirement is met, the file is backed up.
If the mode is absolute, the minimum number of days have elapsed since the file was last
backed up, and the serialization requirement is met, the file is backed up.
If the mode is absolute and the minimum number of days have not elapsed since the file
was last backed up, the file is not eligible for backup.
If files are not excluded and a management class is specified with the INCLUDE option, the
server uses that management class.
If files are not excluded but a management class is not specified with the INCLUDE option,
the server uses the default management class.
If no include-exclude list exists, all files in the client domain are eligible for backup, and the
server uses the default management class.
If there is a backup copy group, the process continues with next step.
If there is no backup copy group, the file is not eligible for backup.
Checks the date and time of the last incremental backup by the client, and the serialization
requirement defined in the backup copy group
Serialization specifies how files are handled if they are modified while being backed up and
what happens if modification occurs.
If the file has not changed since the last incremental backup, the file is not backed up.
If the file has changed since the last incremental backup and the serialization requirement
is met, the file is backed up.
Checks the file against any include or exclude statements contained in the user include-
exclude list
Files that are not excluded are eligible for backup. If a management class is specified with
the INCLUDE option, IBM Tivoli Storage Manager uses that management class.
If no include-exclude list exists, the files selected are eligible for backup, and IBM Tivoli
Storage Manager uses the default management class.
If the management class contains a backup copy group and the serialization requirement is
met, the file is backed up. Serialization specifies how files are handled if they are modified
while being backed up and what happens if modification occurs.
If the management class does not contain a backup copy group, the file is not eligible for
backup.
An important characteristic of selective backup is that a file is backed up without regard for
whether the file has changed. This result may not always be what you want. For example,
suppose a management class specifies to keep three backup versions of a file. If the client uses
incremental backup, the file is backed up only when it changes, and the three versions in storage
will be at different levels. If the client uses selective backup, the file is backed up regardless of
whether it has changed. If the client uses selective backup on the file three times without changing
the file, the three versions of the file in server storage are identical. Earlier, different versions are
lost.
Checks the specification of the logical volume against any include or exclude statements
contained in the user include-exclude list
If no include-exclude list exists, the logical volumes selected are eligible for backup, and
IBM Tivoli Storage Manager uses the default management class.
Logical volumes that are not excluded are eligible for backup. If the include-exclude list has
an INCLUDE option for the volume with a management class specified, IBM Tivoli Storage
Manager uses that management class. Otherwise, the default management class is used.
If the management class contains a backup copy group and the logical volume meets the
serialization requirement, the logical volume is backed up. Serialization specifies how
logical volumes are handled if they are modified while being backed up and what happens
if modification occurs.
If the management class does not contain a backup copy group, the logical volume is not
eligible for backup.
TSM Archive
When a user requests the archiving of a file or a group of files, IBM Tivoli Storage Manager
performs the following steps to determine eligibility:
Checks the files against the user's include-exclude list to see if any management classes
are specified
IBM Tivoli Storage Manager uses the default management class for files that are not bound
to a management class.
If no include-exclude list exists, IBM Tivoli Storage Manager uses the default management
class unless the user specifies another management class. See the user's guide for the
appropriate client for details.
If the management class contains an archive copy group and the serialization requirement
is met, the file is archived. Serialization specifies how files are handled if they are modified
while being archived and what happens if modification occurs.
If the management class does not contain an archive copy group, the file is not archived.
If you need to frequently create archives for the same data, consider using instant archive (backup
sets) instead. Frequent archive operations can create a large amount of metadata in the server
database resulting in increased database growth and decreased performance for server
operations such as expiration. Frequently, you can achieve the same objectives with incremental
backup or backup sets. Although the archive function is a powerful way to store inactive data with
fixed retention, it should not be used on a frequent and large scale basis as the primary backup
method.
To manage files that are not bound to a specific management class, as defined byt he
INCLUDE option in the include-exclude list.
To manage files when a client node is assigned to a new policy domain and the active
policy set does not have management classes with the same names as that to which the
node's files are bound.
Set serialization static or shared static to ensure the integrity of backed up and archived
files
Retain backup versions and archive copies for a sufficient amount of time
Retain directories for at least as long as any files are associated with the directory
Other management classes can contain copy groups tailored either for the needs of special
sets of users or for the needs of most users under special circumstances.
How Files and Directories Are Associated with a Management Class
Binding is the process of associating a file with a management class. The policies defined in the
management class then apply to the bound files. The server binds a file to a management class
when a client backs up, archives, or migrates the file. A client chooses a management class as
follows
For backing up a file, a client can specify a management class in the client's include-
exclude list (include-exclude options file for UNIX and Linux clients), or can accept the
default management class.
For backing up directories, the client can specify a management class by using
the DIRMC option in the client options file.
For backing up a file system or logical volume, a client can specify a management class in
the client's include-exclude list (include-exclude options file for UNIX and Linux clients), or
can accept the default management class.
Specify a management class in the client's include-exclude list (with either an include
option or an include.archive option)
Specify a management class with the ARCHMC option on the archive command
For archiving directories, the client can specify a management class with the archiving
options, or the ARCHMC option.
It is recommended that you define a default management class. If the client does not
specify any archiving options, the server assigns the default management class to the
archived directory. If the default management class has no archive copy group, the server
assigns the management class that currently has the archive copy group with the shortest
retention time.
For migrating a file, a client can specify a management class in the client's include-exclude
options file, or can accept the default management class.
The default management class is the management class identified as the default in the active
policy set. A management class specified with a simple include option can apply to one or more
processes on the client. More specific include options (such as include.archive) allow the user to
specify different management classes. Some examples of how this works
If a client backs up, archives, and migrates a file to the same server, and uses only a single
include option, the management class specified for the file applies to all three operations
(backup, archive, and migrate).
If a client backs up and archives a file to one server, and migrates the file to a different
server, the client can specify one management class for the file for backup and archive
operations, and a different management class for migrating.
Clients at Version 4.2 or later can specify a management class for archiving that is different
from the management class for backup.
A file named REPORT.TXT is bound to the default management class that contains a
backup copy group specifying that up to three backup versions can be retained in server
storage.
During the next week, three backup versions of REPORT.TXT are stored in server storage.
The active and two inactive backup versions are bound to the default management class.
The administrator assigns a new default management class that contains a backup copy
group specifying only up to two backup versions.
The administrator then activates the policy set, and the new default management class
takes effect.
REPORT.TXT is backed up again, bringing the number of versions to four. The server
determines that according to the new backup copy group only two versions are to be
retained. Therefore, the server marks the two oldest versions for deletion (expired).
Expiration processing occurs REPORT.TXT is still bound to the default management class,
which now includes new retention criteria. Therefore, the two versions marked for deletion
are purged, and one active and one inactive backup version remain in storage.
The user changes the management class specified in the include-exclude list and does a
backup.
An administrator activates a policy set in the same policy domain as the client node, and
the policy set does not contain a management class with the same name as the
management class to which a file is currently bound.
An administrator assigns a client node to a different policy domain, and the active policy
set in that policy domain does not have a management class with the same name.
Backup versions of a directory can be rebound when the user specifies a different
management class using the DIRMC option in the client option file, and when the directory
gets backed up.
If a file is bound to a management class that no longer exists, the server uses the default
management class to manage the backup versions. When the user does another backup,
the server rebinds the file and any backup versions to the default management class. If the
default management class does not have a backup copy group, the server uses the
backup retention grace period specified for the policy domain.
Archive copies are never rebound because each archive operation creates a different archive
copy. Archive copies remain bound to the management class name specified when the user
archived them.
If the management class to which an archive copy is bound no longer exists or no longer contains
an archive copy group, the server uses the default management class. If you later change or
replace the default management class, the server uses the updated default management class to
manage the archive copy.
If the default management class does not contain an archive copy group, the server uses the
archive retention grace period specified for the policy domain.
How to configure Tivoli Storage Manager (TSM)
adaptive subfile backup:
A basic problem that remote and mobile users face today is connecting to storage management
services by using modems with limited bandwidth or poor line quality. This creates a need for
users to minimize the amount of data they send over the network, as well as the time that they are
connected to the network. To help address this problem, you can use subfile backups.
TSM Subfile Backup
When a client's file has been previously backed up, any subsequent backups are typically made
of the portion of the client's file that has changed (a subfile), rather than the entire file. A base file
is represented by a backup of the entire file and is the file on which subfiles are dependent. If the
changes to a file are extensive, a user can request a backup on the entire file. A new base file is
established on which subsequent subfile backups are dependent. This type of backup makes it
possible for mobile users to reduce connection time, network traffic, and the time it takes to do a
backup.
The subfile backup pertains to the sections of the files that have changed. To enable subfile
backup, perform the following tasks:
You must set up the server to allow clients to back up subfiles. Issue the SET SUBFILE
command:
The subfilebackup option in dsm.opt specifies whether to enable adaptive subfile backup for this
client
subfilebackup YES/NO
The subfilecachepath option specifies the path where the client cache resides for adaptive
subfile backup processing. If you do not specify a path, Tivoli Storage Manager creates a path
called \cache under the directory where the Tivoli Storage Manager executables reside.
subfilecachepath c:\temp\tsmcache
The subfilecachesize option specifies the client cache size for adaptive subfile backup. If the
cache size is too small, base files for some files will not be cached and subfile processing will not
apply for them. However, setting the value too large can take up more disk space than can be
spared. It Specifies the size, in megabytes, of the client cache for adaptive subfile backup
processing.
subfilecachesize 10
Restoring subfiles
When a client issues a request to restore subfiles, Tivoli Storage Manager restores subfiles along
with the corresponding base file back to the client. This process is transparent to the client. That
is, the client does not have to determine whether all subfiles and corresponding base file were
restored during the restore operation. You can define (move) a backup set that contains subfiles
to an earlier version of a server that is not enabled for subfile backup. That server can restore the
backup set containing the subfiles to a client not able to restore subfiles. However, this process is
not recommended as it could result in a data integrity problem.
When subfiles are exported during an export operation, Tivoli Storage Manager also exports the
corresponding base file to volumes you specify. When the base file and its dependent subfiles are
imported from the volumes to a target server and import processing is canceled while the base file
and subfiles are being imported, the server automatically deletes any incomplete base files and
subfiles that were stored on the target server.
Because subfiles are useless without the corresponding base file, the server processes base files
eligible for expiration differently. For example, when expiration processing runs, Tivoli Storage
Manager recognizes a base file as eligible for expiration but does not delete the file until all its
dependent subfiles have expired. Adding subfiles to backup sets When a subfile is added to a
backup set, Tivoli Storage Manager includes its corresponding base file with the backup set. If the
base file and dependent subfiles are stored on separate volumes when a backup set is created,
additional volume mounts may be required to create the backup set.
Deleting base files
If a base file is deleted as a result of processing a DELETE VOLUME command, the server
recognizes its dependent subfiles and deletes them from the server as well. Subfiles without the
corresponding base file are incomplete and useless to the user.
Full Backup
IBM definition for FULL backup is "Every file on a given computer or file system is copied
whether or not it has changed since the last backup".
TSM server will always take FULL backup when you run the backup for the first time on
your client machine, you cannot change this. You can only use any other types of backups
from second time.
Disadvantage of this type of backup is that all the files will get backup every-time you run
FULL backup, this will cost you waste of network and storage resources.
Differential Backup
IBM definition for differential backup is "A differential backup backs up files that have
changed since the last full backup".
That means, If a file changes after the full backup, the changed file is backed up again by
every subsequent differential backup. Regular Full backups are needed in the regular
intervals to decrease the backup size for example during weekends (Full + differential
backup).
For example, full backup is taken on Sunday and differential backups are taken from
Monday - Saturday. If a file abc.doc is only changed on monday and doesn't change in
any other days, it will still get backup on all remaining days until next Full backup is taken.
Disadvantage of this backup type is that because files which are changed since last Full
backup will get backup in all subsequent Differential backups until the next Full backup is
taken results in waste of network and storage resources.
One advantage of this backup type is (Full + differential backup) gives better restore
performance than in a (Full + Incremental backup), because only two copies of data are
required (the Full backup and the current Differential backup) during restoration of active
client data.
Incremental Backup
IBM definition for incremental backup is "An incremental backup backs up only files that
have changed since the last backup, whether that backup was a full backup or another
incremental backup".
That means, If a file changes after the full backup, the changed file is only backed up in its
next incremental backup but not in all subsequent backups. If a file is not changed, then it
will not be backed-up but make reference to the base file which is backed-up in previous
backups (Full + incremental).
For example, full backup is taken on Sunday and incremental backups are taken from
Monday - Saturday. If a file abc.doc is only changed on monday and doesn't change in
any other days, it will get backup on Monday's incremental backup but not on other days.
Advantage of this type of backup is less data and only one version of the file will be
backed-up, saving network and storage resources.
Disadvantage is that restoring a single file might require retrieving multiple incremental
backup copies as well as the full backup to recreate current (active) file state (Full +
incremental), because each incremental backup will make index/reference to previous
incremental/full backups.
This is the default backup type in Tivoli Storage Manager and it is designed with the
combination of the backup benefits of the incremental approach with the restore benefits of
the differential approach.
IBM definition for Progressive Incremental backup is "After the initial full backup of a client,
no additional full backups are necessary because the server, using its database, keeps
track of whether files need to be backed up. Only files that change are backed up, and then
entire files are backed up, so that the server does not need to reference base versions of
the files".
For example, we can take Progressive incremental backup on all days without taking a Full
backup. Suppose 10 out of 100 files are changed daily, only the 10 files will get backup
and remaining 90 files references will be tracked by TSM database and it will also
consolidates the recovery media for better restore performance.
Restoration processing will be fast because only the requested version of the file needs to
be restored.
TSM automatically releases expired file space to be overwritten, this reduces administrator
intervention and the chance of accidental overwrites of current data.
Over time, less data is moved than in (Full + Incremental) or (Full + Differential )backups,
and data restoration is mediated by the database.
Progressive backups can also be combined with periodic full & selective backups without
disturbing the current backup series, for example half-yearly or yearly.
In Tivoli Storage Manager Version 7.1, DB2 was upgraded to V10.5. If you are upgrading the
server, you must ensure that the correct version of DB2 is installed. If you are using a Tivoli
Storage Manager V6.1 server, and you want to upgrade to V7.1, you must upgrade the V6.1
server to V6.2 or V6.3. Then, upgrade the server from V6.2 or V6.3 to V7.1. The Tivoli Storage
Manager V6.1 server was packaged with a DB2 V9.5 database, which cannot be upgraded to
V10.5. The Tivoli Storage Manager V6.2 and V6.3 servers were packaged with a DB2 V9.7
database, which can be upgraded to V10.5.
3490
3570
CARTRIDGE
OPTICAL
WORM
QIC
DTF
Check list of devices and valid device class in IBM TSM V7.1
From TSM version 7.1, the TSM clients can now automatically fail over to a replicated/target
servers to run restore operations, if the source replication server is unavailable. Limitation for this
feature is that both the source and target replication servers and the client must be at V7.1. You
can use only one failover server for each replicating node at any time. The client can recover data
from the target replication server, but it cannot store data during failover processing.
From Tivoli Storage Manager Version 7.1, You can group file spaces that belong to a single node,
which allows data for these file spaces to be collocated efficiently without requiring separate
volumes for each file space. You should use DEFINE COLLOCMEMBER command to define
members of a file-space collocation group. When you use file-space level collocation groups, you
can group data for a limited set of file systems. Fewer volumes are required for the data and
placement can be coordinated in the server storage hierarchy.
Improved disk migration process for nodes with large number of file spaces
From Tivoli Storage Manager Version 7.1, you can improve the efficiency of the server by using
file space level migration. Nodes with multiple large file spaces can take advantage of faster
migration processing for random-access storage pools.
You can manually configure a Tivoli Storage Manager server, or use the instance configuration
wizard, to use shared memory with DB2. This feature will reduce processor load and improve
throughput, if the database backup performance is slow.
From Tivoli Storage Manager Version 7.1, newly added database directories are now available for
immediate use and parallel I/O performance is improved. You can add directories to the database
by using the EXTEND DBSPACE command. The updates for this operation include distributing
data across all database directories and then reclaiming unused space and returning it to the
system. Because redistribution operations take considerable system resources, plan ahead when
you want to add space to the database. You must complete the process while the server is not
handling a heavy load. A new server utility DSMSERV EXTEND DBSPACE is also available to
perform the same function as the EXTEND DBSPACE command, while the server is offline.
You can now use EMC Centera for versions of Linux x86_64 that are supported by the Tivoli
Storage Manager Version 7.1 server.
Starting from Operations Center V6.3.4, IBM has introduced a new web-based GUI tool to monitor
and manage one or more TSM Servers. Adding to that new features have been added to
Operations Center V7.1, some of them are
View activity log messages that are related to specific alerts, sessions, and processes.
View or cancel the sessions and processes that are in progress by using the Active Tasks
view for servers.
Customize the settings for servers and clients by editing the server and client properties.
TSM Server components that are not supported from Version 7.1
The Administration Center & Tivoli Monitoring for Tivoli Storage Manager are not delivered
in V7.1. You can use the V6.3.4 Administration Center & Tivoli Monitoring for Tivoli Storage
Manager with any Tivoli Storage Manager V6.3 or later server.
Instead, you can use the Operations Center V7.1, a web-based interface for managing
your storage environment. The Operations Center has many of the same functions as the
Administration Center.