M SUDHAKAR GOUD

Why BACKUP
Data Backups: A necessary part of risk management
I. Server or Storage may crash due to any of the following reasons.
A reliable backup is critical requirement.
A power spikes and fluctuation
Equipment Failure Due to Defect or Wear and Tear
Software Bug
Inappropriate patch
Intentional destruction of data
II. Need Deleted Files
Important files may have accidentally deleted while doing housekeeping
III. Need Old Version of a File
Many documents and data files are constantly updated. We need backups to review older
versions
IV. Legal requirement of archival data
Old archived data files may be required for any legal requirement.
V. Requirement of old server logs
System logs , application logs etc may be required for detailed analysis of a issue.

 How much data is changing nightly

Retention policies (how long data is kept and how many copies of each
file)
Point-in-Time Restore requirements (increases the number of copies of
each file that must be kept)
How many nodes will be backed up
What are restore requirements
Network bandwidth

Backup target device is where you want your backups to be saved. Backup target is
chosen wrt following parameters :
1. Criticality of Data
2. Backup Window Availability
3. Backup and Restore Performance
4. Backup Retention
5. Cost Incurred

Welcome to TSM
TSM (Tivoli Storage Manager), a backup tool developed by IBM.
The name Tivoli came from (Reverse of I LOVe IT) and works on the concept of
Manager of Managers.
For a backup to happen we need,
i) TSM server.
ii) TSM client.
iii) Tape library.
TSM server is software that is installed on any of the Windows or UNIX server. TSM
server is responsible for taking backups of all the TSM clients connected to it.
TSM clients can be other Windows or UNIX servers for which backups are taken.

Introduction
IBM Tivoli Storage Manager was earlier called as ADSM (Adstar Distributed Storage
Manager), till IBM took it over.
The product was known as ADSTAR Distributed Storage Manager (ADSM) before its
1999 re-branding, and was originally known as Workstation Data Save
Facility (WDSF).
IBM Tivoli Storage Manager is a client/server program that provides centralized,
automated data protection and storage management solutions to customers in a
multivendor computer environment.
IBM Tivoli Storage Manager provides a policy-managed backup, archive, and spacemanagement facility for file servers, workstations, applications, and application servers.
Versions in Production: 5.4, 5.5, 6.1, 6.2, 6.3

 TSM is the primary backup & data management solution used into the enterprise today. In the other
hand, its a clear winner when it come to the enterprise for many reasons just summarizing few of them
below:
1 TSM Can easily scale up to thousands of nodes without any problem. It has been designed with
enterprise scalability in mind. Most other backup solutions fail to scale up after couple of hundreds of
nodes, but with TSM scalability is a major advantage.
2 IBM Tivoli Storage manager support heterogeneous environment. It support so many platforms
including (Mainframe , AIX, Linux, HP UX, Windows,.etc). It support way more operating systems
& applications than any other backup solution in the market today.
3 TSM have many intelligent data movement and store techniques, that make building a hierarchical
backup .Something which can be very difficult to achieve with other solutions.
4

Its an off-site backup ready, which can be used to build up a disaster recovery plan.

System Admins / Backup Admins

Those who are new to IBM TSM
This presentation may serve as notes to recall / refresh your concepts
It should give you basic understanding

Tivoli Storage Manager

Administrator
Server
Storage Devices
Offsite Storage

Client Nodes

Server Platforms Supported include:

HP-UX
AIX
Windows NT, Windows 2000
Sun Solaris
OS/360-MVS and z/OS (S/390 Edition)

Fast
Access SP

Offsite SP

Slow Access SP

Storage Hierarchy

Storage Manager Functions and Features

Storage Manager
Server

migrate/
recall

backup/
restore

Storage Manager
CLIENTS

archive/
retrieve

Standard Storage Manager

Functions:
Backup and Restore
Archive and Retrieve
Migrate and Recall

IBM Tivoli Storage Manager Components

IBM Tivoli Storage Manager have 9 Components. Six of these components reside on
the TSM Server it self & another 3 are a part of the solution, but does not reside on the
TSM Server.
The first Six components in the list below are the TSM Components which reside on the
TSM Server, where the last 3 components which has been colored in Blue are
components which does not reside on the TSM Server.
TSM Components:
Administrative Interface
Tivoli Storage Manager Server
Scheduler
Tivoli Storage Manager Database
Tivoli Storage Manager Recovery Log
Policy-Based Management
Storage Pools
Tape Library
Backup-Archive Client (BA Client)

Unlike many other backup software, TSM offers multiple management interfaces. Below is a brief of
each
Administration Center GUI: It is the main GUI interface of TSM. It integrates into the Integrated
Solutions Consonle. From it you can do most of the TSM tasks including Managing storage devices,
Domain Policies, Schedules, users, and health monitor, and many more tasks. Its your full
management through the GUI. If you are a GUI lover then this is the interface for you.
TSM Server Command Line: Its the command line interface equivalent of the administration
center. Its the most powerful TSM interface & a great interface for command line lovers. This
interface is accessed by running dsmadmc at the command line.
Backup-Archive Client GUI: it is the GUI interface used to run a manual backup or restore on a
certain client, or to create a customized options for a certain client. Backup-Archive Client is
installed and run on the client server not the TSM Server. It can be accessed by running dsm on
Windows or by running dsmj on Unix.
BA Client Command Line: If you dont like the GUI & prefer command line then this is the
interface to perform all the tasks managed by the Backup-Archive Client GUI, though using
command line. This can be accessed by running dsmc at the windows command line.
Web Client GUI: Well this is nothing more than a web interface access to the Backup-Archive Client
GUI. It actually look exactly the same as the Backup-Archive Client GUI, beside of being running in
a web browser.

dsmadmc: is to call the TSM Server Command line. You will need this interface when
you are planning to perform administration tasks on the TSM Server.
dsmc: to call the BA Client Command Line to perform tasks on the client server (the
servers you want to backup).
dsm: to call the BA Client GUI. Again to perform tasks on the client server (the server
you want to backup).
So dsm & dsmc is interfaces which manage tasks on the client (the server you want to
backup)
where dsmadmc is to manage tasks on the TSM Server.
Please make sure to get this straighten up before proceeding as this will make your life a
lot easier while switching between these interfaces in future chapters

Tivoli Storage Manager Server

The IBM Tivoli Storage Manager (TSM) software product addresses the needs of todays
heterogeneous computing environments by providing storage management services for
data (primarily backup/restore and archive/retrieve) using a client/server model.
TSM Server main functionality is to move the backup & archive data from the BA Client
to the storage media (Storage or Tape Library). TSM Server keep all of the users,
administrators, policy management objects, & client nodes data into a special database.

Tivoli Storage Manager Server

The policy-driven implementation allows for a consistent methodology of grouping
client data for storage management.
This policy-driven structure is the foundation of the management
scheme for the data contained within TSM.
Example :
Assume that a company has two departments that have different data storage needs.
The accounting department might require that financial data be accessible for 3 years
from the time it is backed up.
The marketing department might only require that their data be available for 5 months
from the time it is backed up.
Tivoli Storage Manager allows for policies to be created centrally so that data is
managed for both departments appropriately.

Tivoli Storage Manager Server

The server also controls the management of storage pools that store the client backup
and archive data. Each storage pool represents a single type of storage media
(referred to by TSM as a device class).
For example, one storage pool might represent a pool of random access disks, another
of sequential access tapes

 Methods of accessing TSM server

GUI [ Graphical Interface ]
CLI [ Command Line Interface ]
ISC Admin [ Integrated Solution Console ]
- Now renamed : Tivoli Portal [ Centralized administration ]

 The administrative interface allows administrators to control and monitor

server activities, define management policies for clients, set up schedules for
clients, and other functions.

 Administrators with system privilege can perform any TSM server function.
Administrators with policy, storage, operator, analyst, or node privileges can perform subsets of
TSM functions.
Privileges are granted to an Administrator through the grant authority command.
The levels of authority and the privileges those levels provide are provided in the following list.
System: All Tivoli Storage Manager server tasks.
Storage: Database, recovery log, and storage pool management.
Unrestricted storage privilege allows the administrator to manage all storage pools.
Restricted storage privilege allows the administrator to manage specified storage pool or pools.
Operator: Commands for server availability and media management.
Policy: Policy domain, policy set, management class, copy group, and schedule management.
Unrestricted policy privilege allows the administrator to manage all policies.
Restricted policy privilege allows the administrator to manage a specified policy.

 Analyst: Review and reset server statistics.

Node: Client actions, product usage, and activity monitoring.
The analyst and operator privileges have limited functionality, and thus are only used in rare
cases.

When administrators are first registered they can only issue a limited set of TSM server
commands, such as queries and help commands.
To perform other TSM functions they must be granted a higher authority by being assigned
one or more administrative privilege classes.

 The basic TSM clients are called nodes. A TSM client must connect as a node in
order to back up data to a TSM server. The TSM node name is the login account on
the TSM server.
Commonly, the node name is the same as the clients machine name or host name,
although this is not necessary.
The TSM backup-archive client node must first be registered with the TSM server.
The TSM client authenticates with the TSM server by completing a sign-on process.
This sign on process requires a node name and a password.

Backup-Archive Client
The TSM backup-archive client must be installed on every machine that needs to transfer
data to server-managed storage called storage pools.
The TSM server uses a unique node name to identify each TSM backup-archive client
instance.
The TSM client can be installed and used on various operating system platforms.
Regardless of operating system platform or file format specifications of either the TSM
client or TSM server, TSM clients can send data (such as a backed-up file) to be stored
by any TSM server on the same
network.
For example, a TSM client on a Microsoft Windows system can back up files to a
TSM server on an AIX system.

 The TSM backup-archive (B/A) client is the clients component of the TSM client/server
relationship.
This software is installed on each machine that needs data management services and is separate
from the TSM server software.
The purpose of the TSM client is to protect data against corruption or loss by sending copies of
files, directories, and operating system specific data to a TSM server as either backup data or
archive data.
The two basic methods clients can use to send and receive data to and from TSM storage are:
Backup and Restore: Used for more frequent, versioning-dependent operations. The backup
feature enables users to back up to the TSM storage pool hierarchy and manage a number of
versions of their data. It also provides the capability to recover files that are lost or damaged.
Typically, backup is performed on transactional data, which is data that changes on a regular,
frequent basis.
The restore function allows you to select the version of the file you want to restore. Data can be
restored to the original location or to the location a user chooses.

Backup and Restore

 Archive and Retrieve: Used for long-term storage, archive has no versioning. The archive
feature enables users to keep a copy of their data for long-term storage and to retrieve the
data if necessary.
Examples of this need might be to meet legal requirements for data retention, or to archive
files that are not needed locally on a workstation.

TSM Client GUI

The graphical user interface (also known as the GUI) allows users to easily perform operations
using the mouse.
This interface is supported only on those systems that support a mouse.
The executable to start the client GUI is dsmj (or dsm.exe on Windows), which is in the TSM
backup-archive client install directory.

 TSM Command Line Client (CLC) This interface is available on all operating system
platforms. All GUI functionality exists in the CLC, but not all command line functions are
available in the GUI.
The executable to start the TSM B/A client command line is dsmc (and dsmc.exe on Windows),
which is in the TSM backup-archive client install directory.
A client command session can be started in either batch or interactive mode.
Batch mode allows single client commands and then returns to the command prompt. To use
batch mode, simply issue dsmc and the command together.
For example, to archive the file c:\myfiles\file1.dat, enter the following command:
dsmc archive c:\myfiles\file1.dat

 Interactive (or loop) mode is used to issue a series of commands. you can process a series of
commands more quickly in interactive mode than in batch mode.
Simply issue dsmc to start the interactive mode.
The TSM client will establish a session with the TSM server and then display a prompt on your
screen

 The configuration file that defines how a client will connect to the TSM server depends on the
operating system that the client uses. Some typical options are:

COMMMETHOD specifies the protocol for communication.

SERVERNAME specifies the name of the TSM server.
TCPSERVERADDRESS specifies the TCP/IP address of the TSM server.
TCPPORT specifies the TCP/IP port for the TSM server.
NODENAME specifies the node name to connect to the server with.

There are two client options files:

dsm.opt for Windows clients
dsm.opt and dsm.sys for Mac OS X and all UNIX or Linux clients
The dsm.opt and dsm.sys methodology allows for different configuration parameters to be
specified within a multiuser environment.
The dsm.opt file itself specifies a minimal number of options. The most important option is the
SERVERNAME clause, which points to a stanza within a dsm.sys file.

TSM Introduction to DB & LOG

The TSM database and recovery log are vital to the operation of the TSM server.
If the TSM database reaches 100% full it will severely degrade the operation of the TSM server.
If the recovery log reaches 100% full the TSM server will halt.
It is important to monitor the size of both the database and log.
The TSM database is where the inventory of which data belongs to which node, where the data is
stored etc.
The database should be backed up at least daily.
The recovery log is where transactions are stored before they are committed to the database.

TSM Introduction to DB & LOG

TSM Introduction to DB & LOG

If the recovery log is reaching 100% full you can perform a database backup, and then
extend the log so that there is minimal risk of the database reaching 100% full again.
It is a good idea to have a sequential disk device class to perform backups to disk as well as
to a daily tape
To check the size of the database you would use the
query db command:
To check the size of the recovery log the query log command is used
The command to format a new database volume is:
Define dbvolume /var/tsm/tsmdb/dbvol05.dsm formatsize=megabytes

 DATABASE
5.x version
RDBMS
530GB
6.x version
DB2 9.7
1 TB

* Full / Inc / Snapshot Backups

LOG
5.x version
13 GB
6.x version
128 GB
Normal / Roll forward

Tivoli Storage Manager Recovery Log

The recovery log, which is structured like the Tivoli Storage Manager database, keeps track
of all changes made to the database.
A primary reason for using a recovery log is for error handling. If a file transfer is
interrupted, the TSM server will not erroneously commit information to the database. Using
the recovery log allows the TSM server to maintain a consistent database image in case of
interruption

For example :
suppose a client performs a backup operation.
It first notifies the TSM server to start a transaction and the TSM server marks the
start of the transaction in the recovery log.
The client then sends data to the TSM storage pool in blocks.
After all of the data is sent, the client notifies the TSM server that the transaction is
complete.
After successfully completing the transaction, the TSM server commits the
transaction from the recovery log to the TSM server database.

A primary reason for using a recovery log is for error handling. If a file transfer is
interrupted, the TSM server will not erroneously commit information to the
database.
Using the recovery log allows the TSM server to maintain a consistent database
image in case of interruption.

 Utilization is the percent of the assigned capacity in use at a specific time. The value
represented by Max % Util is the highest utilization since the statistics were reset.
For example, assume that
A TSM environment performs most backups after midnight.
Examine the three examples in the following graphic.
The first picture (far left) shows the utilization statistics for the recovery log after being
reset at 9:00 p.m. the previous evening.
The middle picture shows the maximum utilization occurring at 12:58 a.m.
The last picture shows the utilization at the current time.

In Precise :
Normal - can restore to last database backup and consists of uncommitted
transactional data.
Where as roll -- can restore to most recent state and consists of all transactional data
since last backup
Syntax
>>-Set LOGMode-+- Normal------+--------------------------------><
'- Rollforward-'

 NORMAL
In Normal recovery log mode when the transaction is committed on DB The recovery log
Erases information about DB
Data after Last DB backup is LOST
The recovery log only stores the records needed to restore the database to a point in time.
You can not recover changes made to the database after the last database backup in case of disaster
or any failure.
This is the default log mode, all committed transactions are erased from log and written to
database.

Scenario : 1
The TSM administrator backs up the database on January 5 (type=full) and uses a normal
recovery log.
There are no additional database backups performed and the TSM server database volumes are
lost on February 7.
The database can only be restored to its January 5 state.
Scenario : 2
The TSM administrator backs up the database daily at 12:00 and uses a normal recovery log.
At 17:00 on February 7, the database volumes are lost in a disaster. The database can be
restored to the state it existed in on February 7 at 12:00.

 ROLL FORWARD
In Roll forward mode when the DB backup is completed only then, the information about the
DB is erased.
No loss of client data
Keeps all transaction since last DB backup.
The recovery log stores all records to restore the database to its most current state.
The recovery log becomes large in size if a database backup is not done. You can define a database
backup trigger to prevent this from happening.
In rollforward mode the recovery log is cleared only by database backup.

Scenario : 3
The TSM administrator performs a full backup of the database every 3rd, 10th, 17th, and 24th of
the month.
Incremental database backups are performed daily (at noon). The recovery log mode is set to roll
forward.
On February 7 at 17:00, the database volumes are damaged but the recovery log volumes are still
intact.
The TSM administrator then uses the full database backup from the 3rd, the incremental backups
from the 4th, 5th, 6th, and 7th, and the recovery log to recover the database to the state it was in
before the disaster.
-------------------------------------------------------------------------------------------------------------------Roll-forward recovery logging enables you to recover a database to the most recent version
without having to constantly perform database backups.
This protection does require system resources such as disk space, and you must perform periodic
database backups to clear out old transactions.
** Additionally, note that database snapshot (type=DBS) backups cannot be restored
to a current point in time. They will only allow for a restore to the state of the TSM server
database at the time when the database snapshot was taken.

Tivoli Storage Manager Database

Tivoli Storage Manager saves information in the Tivoli Storage Manager database about each file,
raw logical volume, or database that it backs up, archives, or migrates.
This information includes :
1.The file name,
2.file size,
3.management class [ backup / archive ]
4.copy group [ retention policies ]
5.location of the files in Tivoli Storage Manager server storage, and all other information except
for the data. Data is stored in a storage pool.
The Tivoli Storage Manager database is the heart of IBM Tivoli Storage Manager.

TSM Database
The TSM database contains all information required to perform backup and
restore functions.

Restore

If you lose the TSM database, you can no longer restore files.

Database has three

sections, for simplicity :
1.Files or Data
information
2.Policies / rules
3.Tracking / location

The TSM server database is viewed by

the TSM server as a single logical entity
that is comprised of one or more database
volumes.
Database volumes represent a
preformatted space allocated on a hard
drive.
Each volume requires an additional
megabyte of space for overhead.
For Example, assume that the TSM
server has five physical database volumes
defined on the OS, where DBVOL1 is
101 MB and DBVOL2 through DBVOL5
are 25 MB each.
After allocating the 1 MB of overhead
per volume, the TSM server would have
196 MB of available space for the
database.

The database contains information about the client data and information regarding the location of
that data within your storage pools.
Note: If you lose the database, you lose all of your client data.
If the TSM database were destroyed or corrupted, client files within the storage pools
would still exist.
However, you would not be able to locate any of the files within the storage pools.
To recover from disasters involving the TSM database volumes, regular backups of the database
must be performed with the backup db administrative command. A TSM administrator can
perform a database backup to sequential access storage volumes.

There are three types of database backups:

Full backup (type-full) copies the entire TSM database to one or more sequential volumes.
Incremental backup (type=incremental) copies only those database pages that have been added
or changed since the last time the database was backed up (type=incremental) to one or more
sequential volumes.
The first backup of the database must be a full backup. Up to 32 incremental backups can be taken
between full backups.
DBSnapshot (type=dbs) specifies that you want to take a full snapshot database backup.
A DBSnapshot is similar to a full backup but does not allow incremental backups or recovery log
transactions to be applied to it.

Snapshot copies the entire database, just like FULL backup

Snapshot does not interrupt FULL + INC series
Snapshot does not Flush / Erase recovery log post backup

 BAckup DB DEVclass= < device_class_name > Type=Incremental / Full /

DBSnapshot VOLumenames= < volume_name > Scratch= < Yes / No >

 There are TWO types of Restores wrt DB

PIT recovery : can not restore to the current state / Auditing of storage pool is required post
restoration.
ROLL FORWARD recovery : can restore to most recent state
Dsmserv restore DB devc=<> vol=volname commit= < yes/no >
Example :
Restore the database to the time of its most recent incremental backup. The volume history file
is not available. Tape volumes FULL1, FULL2, INCR1, and INCR2 contain the database
backup series.
dsmserv restore db devclass=tape volumenames=full1,full2 commit=no
dsmserv restore db devclass=tape volumenames=incr1 commit=no
dsmserv restore db devclass=tape volumenames=incr2 commit=yes

 Restore a database to the time of its most recent snapshot backup. The volume history file is not
available. Tape volumes TAPE01 and TAPE02 are snapshot volume names in a volume sequence
that spans two tapes.
dsmserv restore db devclass=tape volumenames=tape01,tape01 commit=yes

def spacetrigger < db / log > spaceexpansion=<%> expansionprefix=< /usr/tivoli/tsm/server/bin/ >

Tape Library

IBM Tivoli Storage Manager supports a variety of library types, including

manual libraries, SCSI libraries, 349X and 358X (LTO) libraries, and external
libraries. A tape library is essentially a box that holds drives and cartridges,
and provides automation for tape operation.

Tape Library : Peripherals

Library A device that organizes and holds one

or more media (tape or disk) volumes, and an
optional robotic mechanism. Use define library
command.

Device Class Represents a device type which

defines the media used in the library. Use the
define devclass command.

Drive A hardware device capable of

performing operations on a specific type of
sequential media. Use the define drive
command.
Slot The storage media location in the library.
Use the define path command.

Installing and Configuring a Media Library

The devices in a library, such as the changer and

drive or drives, are physically attached to the
server using SCSI or Fibre Channel.
The OS uses special software called a device
driver (or driver) to control a physical device.
A device driver is a program that links the OS
to a peripheral device and allows the OS to
control that particular type of device attached to
your computer.
The driver contains the precise machine
language necessary to perform the functions
requested by the OS.
* In other words, a device driver essentially
converts the more general input/output
instructions of the OS to instructions that are
specific to the device.

All connected libraries

will be listed in the wizard.

Use tsmdlst to Find Devices on Windows

1. Click Start > Programs > Accessories > Command Prompt. The command
prompt dialog box appears.
2. Change directories to the directory in which the Tivoli Storage Manager
Console been installed. For default installations, the path is:
c:\program files\tivoli\tsm\console
3. To view the information, enter the following command:
tsmdlst > devlist.txt
4. To view the file, enter the following command:
notepad devlist.txt

# lsdev -Cc disk

hdisk0 Available 40-60-00-4,0 16 Bit SCSI Disk Drive
# lsdev -Cc tape
rmt0 Available 1P-08-00-0,0 4.0 GB 4mm Tape Drive
rmt1 Available 1P-08-00-2,0 4.0 GB 4mm Tape Drive
smc0 Available 1P-08-00-3,0 IBM 7336 Tape Medium Changer
# lsdev -Cc adsmtape
mt0 Available 1P-08-00-0,0 Tivoli Storage Manager Tape Drive
mt1 Available 1P-08-00-2,0 Tivoli Storage Manager Tape Drive

Define a library:
define library <robotmount> libtype=scsi
Define a tape path for the library:
define path <server1> <robotmount> srctype=server desttype=library
device=lb3.0.0.0
Define a drive:
define drive <robotmount> <tap01> elem=autodetect
Define a path for the drive:
define path <server1> <tap01> srctype=server desttype=drive
library=<robotmount> device=mt3.0.0.0

Device Class
Define additional tape device classes to reflect specific devices, media, and
procedures.
DEFine DEVClass DEVType=type of device
def devc autodlt_class devt=dlt library=autodltlib00

 Disk storage can provide optimal restore for small/medium files

No delays for mounting of volumes
Fast positioning to data within volume
Simultaneous volume access from multiple sessions for random-access
volumes
Random-access disk storage pools defined with device class of DISK
Sequential-access disk storage pools defined using device class LTOCLASS

Random-access disk
A
B

Objects stored in random blocks

A
A
B

C
A

Sequential-access
Objects stored sequentially in volumes

Disk or Tape Backup Overview

There are two types of Storage pools:

Random access
Tivoli Storage Manager provides a predefined disk device class that is
used with all disk devices.
Sequential access
To create large, sequential access file-type storage pools,
issue the following command:

define devclass devclassname devtype=< >

 Tape remains the most Ideal backup target

Tape is an ideal medium for backing up data because of its high storage capacities,
low cost, and the ability to store cartridges off-site.
A tape drive is a data storage device that reads and writes data on
a magnetic tape. Tape drive can be a standalone external tape drive or Library based
tape drive supported by robotic control.
Tape media generally has a favorable unit cost and long archival stability.
A tape drive provides sequential access storage

 Linear Tape-Open (LTO) is a magnetic tape data storage technology. Following are
the LTO Generations and their properties.

Reference link : http://www.lto.org/technology/generations.html

SCRATCH VOLUMES:
Are empty or contain no valid data.
Change status to PRIVATE when data is written to them.
Can be used to satisfy any request to mount a scratch volume.

PRIVATE VOLUMES:
May contain valid data.
Are used or owned by an application.
Can only be used to satisfy a request to mount the specified volume.

 A disk drive can move its read/write head(s) to any random part of the disk in a very short amount of
time.
A Disk provides random access storage.
In several scenarios disks are used as intermediately storage devices to
speed up the backups.
Disk can also be used for backups which need to be retained only for short
duration.
Disk Drives, CD, DVD, Flash-disk etc can be used as backup targets.
Advantages :
1. Fast Backup & Restores
2. Reliability

 A typical implementation has these pools:

Disk storage pool where client data initially gets stored

Disk storage pools are usually limited in size due to the price per GB.
Ideally, this disk pool is large enough to store one to two nights of backups.
A subordinate tape storage pool, known as the next storage pool
Files that are too large for the initial pool are stored directly to this next pool.
As the initial pool fills to capacity, TSM migrates stored data to this next pool

more expensive

faster

Storage Pool Hierarchy

slower

less expensive

Storage pools can be chained

to create a storage hierarchy.

Creating or Defining Storage Pools

Use the following command to define a storage pool:

DEFine STGpool poolname devclass

For example:
DEFine STGpool lastinchain devclass=disk

81

Defining Storage Pool Volumes for Disk

Commands to define storage pool volumes:
DEFine VOLume poolname volname Formatsize=Format_size
DEFine VOL BACKUPPOOL /usr/tivoli/tsm/dbvol/vol6 Formatsize=200
DEFine VOL ARCHIVEPOOL E:\dbvol\vol5 F=200

Backing Up the Storage Pool Hierarchy

Primary Storage Pools

Active-Data Storage Pools

Copy Storage Pools

 Client data is always stored in a primary storage pool.

When a user tries to restore or retrieve file
data, the TSM server will first attempt to obtain the file from a primary storage pool.
Primary storage pool volumes are locally available to the TSM server.
A primary storage pool can be either random or sequential access.

 A copy storage pool provides an additional level of protection for client data.
Copy storage pools contain copies of the data in one or more primary storage pools.
The process responsible for copying the data from the primary pool or pools to a
copy storage pool is called the backup storage pool process.

 Active-data pools are storage pools that contain only active versions of client backup
data.
As newer versions of data are stored in the active-data pool, the older versions are
deactivated and removed during reclamation processing.

Active-Data Pools and the Storage Hierarchy

Copy storage pool:
Copies of active or inactive
data from primary storage
pools for offsite storage.
Active-data pools on disk:
Copies of active data for fast
restore of client data.

storage hierarchy with

active and inactive data

Active-data pools on tape:

Copies of active data to reduce
the number of tapes stored
offsite.

How to Move Data

MOVE DATA
You can move files from one volume to another volume in the same or a
different storage pool using the MOVE DATA command.
move data source_vol_name target_STGpool

The label libvolume command:

label libvolume storagelibname checkin=scratch search=bulk
labelsource=barcode
Search=yes Specifies that the server labels only volumes that are stored in the
library
Search=Bulk Specifies that the server searches the library entry/exit ports for usable
volumes to label.
If you specify LABELSOURCE=BARCODE, the volume bar code is read

checkin libvolume tapelib search=yes status=scratch

query libvolume

checklabel=barcode

Checklabel
Yes : server reads the media label during check-in
No : Doesnt read the media label during check-in
Barcode : server reads the barcode label during check-in [ decrease the checkin time by using the barcode ]

TSM mounts each volume and verifies the internal label

before checking it out.
After being checked out, the volume is moved to the entry
or exit port if the device has one. If it does not, the operator
is requested to remove the volume from the drive within
the device.

checkout libvolume
checkout libvolume tapelib volx checklabel=yes remove=bulk

Scenario :
After the scratches are requested - to have them loaded in library
tsm: TSM_PRI>checkin libvol 3576LIB checklabel=barcode search=bulk status=scratch
ANS8003I Process number 123 started.
tsm: TSM_PRI>q req
ANR8352I Requests outstanding:
ANR8373I 001: Fill the bulk entry/exit port of library 3576LIB with all LTO volumes to be
processed within 60 minute(s); issue 'REPLY' along with the request ID when ready.
tsm: TSM_PRI>rep 001
ANR8499I Command accepted.

Start reuse if defined to storage pool.

vol002
vol007
vol002
vol008
vol008
vol007

In step 2, vol007 and

vol008 are manually
removed and replaced.

The AUDIT LIBRARY command will update the library inventory.

 IBM Tivoli Storage Manager is a backup & archive solution, so if you are familiar with backup
solutions you will discover that TSM will have to be capable of performing four main functions:
backup, restore, archive, and retrieve.
Although these concepts seem easy to most, many new admins have a hard time distinguishing between
backup & archive. Here, you will find a brief of each as being defined by IBM Tivoli Team.

Backup: Creates a copy of a file to protect against the operational loss of destruction of that file.
Customers control backups by defining the backup frequency and number of versions.
Restore: Places backup copies of files into a customer-designed system or workstation after the loss of
a file. by default, the most recent version of each active file requested is replaced.
Archive: Create a copy of a file or set of files for vital record retention of data, such as patent
information, financial information, or customer records. Customers control archive by defining the
retention period. This feature enables customers to keep unlimited archive copies of a file.
Retrieve: Allows users to copy an archive file from the storage pool to the workstation. The Archive
copy in the storage pool is not affected.
Basically the main difference between archive and backup, is backup meant for the situation where you
loose the data and you need to recover. In the other hand, you require the archive to meet certain
auditing requirement of keeping certain data for a certain period of time.

Backups
Recovery from oops situations
Different parameters to control how many versions of each
Point-in-Time Recovery

Archives
Long-term storage or package backups
Single parameter: How many days to retain
Example: Long Term Month-End and Year-End Backups
Example: Maintain files for an ex-employee for 90 days

file are needed

Identify the Client Interfaces

Command Line
Web Client Session
Backup-Archive GUI

The Backup-Archive Command Line

TSM
server

dsmc

backup-archive
command line

Start the client command line at the operating system prompt. Your path may
vary, but the default paths are as follows:
Windows:
Program Files > Tivoli > TSM > baclient
AIX:
/usr/tivoli/tsm/client/ba/bin

Backup-Archive Command-Line Syntax

Rules of command-line syntax are as follows:
When using the command line, the command syntax rules must be
followed. All commands begin with dsmc (in lower case letters on some
platforms).
Options are always preceded with a dash (-), and often times followed by
an equal sign (=) with a value assigned to the option.
The file specification follows the rules of the platform. For example, a
DOS file specification might read: C:\USER\MYFILE.DAT
HELP is available on all commands using the help or ? command
following the dsmc prefix.

 The following are essential for a backup to start :

DSM.OPT [For UNIX machines dsm.sys & dsm.opt files ]
TSM Scheduler services
DSM.OPT
The dsm.opt files is considered to be the HEART of any backup & no backup can happen
with out this file.
Location :
For windows : C:/Program files / Tivoli / TSM / BA Client /
For Unix clients :

/opt/tivoli/tsm/client/ba/bin/
( or )
/usr/tivoli/tsm/client/ba/bin/

Backup-Restore Functionality with IBM Tivoli Storage Manager

BACKUP
The backup-archive
clients send copies of
files to Tivoli Storage
Manager server.

The Tivoli Storage

Manager server stores the
copies in the storage
pools.

RESTORE
The files are returned to
the backup-archive client.
.

When a restore is requested by

the backup-archive client, the
storage pool sends the copy
back to the server.

BACKUP - Select Files and Perform a Backup

Click the Backup button.

Select the type of
backup.

Select the objects

to back up.

Click the box to the left of the

directory to select all files in a directory
for backup.

Click the folder next to the

directory to see the list of files
selected for backup.

Review Backup Results

 Incremental :
Tivoli Storage Manager uses a method for backups they call Incremental Backups.
Essentially, a full backup is only taken once - the first time the system is introduced
to backups. Subsequent backups are incremental backups, that only backup files that
have changed or are new.
TSM tracks this data internally by considering every file that exists on the system
during the most recent backup as active.
TSM makes that new version active and marks the previously stored version
as inactive. The policies that define data retention in TSM define how many inactive
copies are stored in TSM and for how long. Once an inactive copy has expired out of
TSM, it is no longer recoverable.
FULL Backup : Every file on a given computer or file system is copied whether or
not it has changed since the last backup

During incremental processing, the TSM client queries the TSM server to determine the exact state of
your files.
A new copy of the file is sent to the TSM server if changes are observed on any of the following
attributes:
File size.
Date or time of last modification.
Extended attributes.
Access control list.
NTFS file security descriptors. These are the Owner Security Identifier (SID), Group
SID, Discretionary Access Control List (ACL), and System ACL.
Depending on the operating system, other characteristics such as NTFS file security descriptors and
extended attributes can be evaluated.
If any object exists in the list of objects from the TSM server but not in the list of objects from the
client, the active object on the TSM server is marked inactive.

Perform an Incremental Backup on the Command Line

Configuring Client Options

There are two files which retain client options, and whichever is used
depends on the operating systems:

Windows

UNIX
dsm.sys

dsm.opt

dsm.opt

dsm_ARISAM_tdpo.opt
SERVERNAME ARISAM_tdpo

dsm_ARIS62_tdpo.opt
SERVERNAME ARIS62_tdpo

Option file #1 (c:\tsm\dsm.opt1)

Option file #2 (c:\tsm\dsm.opt2)

Editing the Client Options File with the GUI

Edit from the GUI

From the Utilities menu, select Setup Wizard. This will launch the Tivoli
Storage Manager Client Configuration Wizard.
On the first panel of the Tivoli Storage Manager Client Configuration
Wizard, make sure Help me configure the TSM Backup Archive Client is
selected.

Edit from the GUI graphical

options editor
Edit > Preferences

Configure Client Access to the Server

communication method
TCP port
TCP server address

node name

The following communication parameters must be set in the

client options file:

TCPPORT
TCPServeraddress
COMMMethod
NODename

 Domain
The domain statement in the client options file (or TSM server client options set) specifies the drive letters or file system mount points to be considered
for client processing. The default option is all-local.
For example:
Domain c: d: e: (processes the c, d, and e drive letters)
Domain all-local d: (processes all local drives except the D: drive)
Domain /home /usr (processes the /home and /usr file system mount points)

 The include/exclude list controls which files are processed during a backup procedure.
By default, the clients include/exclude list is stored in either the dsm.opt or the dsm.sys file, depending on the
operating system of the client.
Optionally, users can specify an INCLEXCL option that points to a file containing include and exclude statements.
When processing an include/exclude list, the client evaluates each object against the individual statements. The client
reads each statement in the list from the bottom up and stops on the first match.

For example, consider the following include/exclude list.

Exclude c:\...\*
Include c:\topsecret\...\*
Exclude c:\topsecret\secretplan.doc

When the client evaluates c:\topsecret\secretplan.doc, it will find a criteria match against the bottom statement in the include/exclude list and exclude the
file.
When the client evaluates c:\topsecret\todd.doc, it will not match the bottom statement but will match the middle statement. It will then decide to include
the file.
When the client evaluates c:\autoexec.bat, it will not match the middle or bottom statements but will match the top statement and exclude the file.

If no matches are found, TSM will include the file by default.

Include-Exclude Processing Rules

The list is read

from the
BOTTOM UP.

STOP
(when
you make
a match).

If it is not
EXCLUDED,
it is
INCLUDED.

Include-Exclude Example

C:\TSM\critproj1\my.doc
(rule 3)

Yes
C:\TSM\critproj2\user.doc
(rule 2)

D:\TSM\critproj1\form.txt
(default)

Yes
Yes

E:\TSM\data\base.doc
(rule 1)

No

Exclude Directories from Backup

The EXCLUDE.DIR statement excludes a

directory structure from the internal traverse
tree that the Tivoli Storage Manager
backup-archive client builds internally
before performing the backup. It prevents
directories and directory attributes from
being backed up.

If you use the following EXCLUDE.DIR statement:

EXCLude.dir c:\TSM\critproj2\subdir1
What will happen to the costs file?
What will happen to the plans file?
What will happen to the dates file?

Identify Files to Be Included or Excluded from Backup

TSM server
You can assign a management class for a file or file group by using an
INCLUDE statement in your client options file.
For example, to associate all the files in the costs directory with a management
class named critproj, you would enter:
Include c:\tsm\critproj2\costs\* critproj

Exclude Include

Excluded directories appear on

the backup-archive tree with this
icon:

Include-Exclude in the Backup-Archive Tree

 examples of exclude rule syntax

Include-Exclude

The default is to include a file for backup.

If a file does not match either an Exclude or Include directive in the configuration file then it will be
included for backup.
The include/exclude list is processed bottom up. If you add the following two lines to the bottom of the
configuration file
Include C:\XYZ.DOC
Exclude C:\XYZ.DOC
then the file XYZ.DOC will not be backed up. The processor will read the list from bottom up, and acts
on the first, and only the first, directive that applies. In this case, the Exclude directive is read first,
applied and the processor then grabs the next file and so on.
To specify a directory path or filename with spaces in it, enclose it fully in quotation marks, as
below:
Exclude "C:\My Documents\tempfiles\*"
Exclude "C:\Program Files\xyz\*
To exclude the contents of a directory and all its subdirectories, use the Exclude.dir directive:
Exclude.dir C:\testdata

Include-Exclude
Exclude.dir directives are processed before all other directives.
Example :
If you add the following two lines to the bottom of the configuration file :
Exclude.dir C:\testdata
Include C:\testdata\test1\summary.dat
then the file "summary.dat" will not be backed up even though the Include directive is below the
Exclude.dir directive.
The Exclude.dir directives are read and processed first.
To check the order in which exclude directives are processed open the TSM command line client
& enter the following :
tsm> query inclexcl

Return
Code

MEANING
.

.
.
.

Restore

Can restore active or inactive

Pick and Choose any files

Point-in-Time Restores

Restores can be restarted (and state of session preserved) if interrupted

interactive or GUI

Restore Backed Up Files Using the dsmc restore Command

Restore the c:\Program Files\bobm.ppt file to its original directory.

If you do not specify a destination, the files are restored to their original location.

dsmc restore c:\Program Files\bobm.ppt

Restore : PICK Option

The PICK option creates a list of backup versions, images, or archive copies that match the
file specification you enter. From the list, you can select the versions to process.
Include the INACTIVE option to view both active and inactive objects.

dsmc restore -pick -inactive c:\data\*

Restore : Overwrite
Restore all the files matching strat*.doc to their original locations,
overwriting existing files.
dsmc restore replace=yes c:\Data\strat*.doc

Restore : Active and Inactive Versions

1
Before you select the file
you want to restore:
1. Click View
2. Select Display
active/inactive files.
When you select the files
you want to restore, you
have a list of active and
inactive files.

Modify Restore Options

1

1. Select a file to restore

and click Options.
2. Select Replace from the
menu, and click OK, and
Restore.

Restore : Point-in-Time Restore

A Point-in-Time Restore restores files to a past state that existed at a specific
date and time, as opposed to the current state of the last backup.

Archive-Retrieve Functionality with IBM Tivoli Storage Manager

ARCHIVE

RETRIEVE

The backup-archive
clients send copies of
files for retention to
Tivoli Storage Manager
server.

A copy of the files are

returned to the backuparchive client.
.

The Tivoli Storage

Manager server stores the
copies in the storage
pools.

When a retrieve is requested by

the backup-archive client, the
storage pool sends a copy of the
data retained in the storage
pool.

Backup Sets
A backup set is a group of active versions of
files, copied onto portable media.

Must be generated
by an
administrator.

Can be used to restore without a TSM server

present from locally attached media
(CDROM,etc.)

up
Back
set

136

 Backup set has the data which is encrypted in lower lever which only requires BAclient to read
the data
Backup set can be dumped on CD / DVD [ This can work with out the TSM server connection
Instead of providing a complete TSM infrastructure to the CA for audit It is best to have the
backup set provided

Schedules
TSM has 2 types of schedules and they are as follows:
Backup/Archive Schedules
Admin Schedules
Backup/Archive Schedules are used to automate client backups and archives. Upon
defining a backup/archive schedule >> you will have to associate the client(s) to that
schedule for the backups/archives to run automated.
Admin Schedules are designed to automate admin tasks such backing up the DB, copying
data from the primary backup pools to the copy pools, reclamation, backup volhistory file,
backup devconfig file etc.

Two types of scheduling:

Client scheduling

Administrative scheduling on the server

Sequence of Admin schedules :

BACKUP STGPOOLS
BACKUP DEVCONFIG
BACKUP VOLHIST
BACKUP DB
PREPARE
EXPIRE INV
RECLAIM
MIGRATE STG

CLIENT BACKUP WINDOW STARTS

Daily Administration Cycle

incremental backups
of client data

back up first stgpool

back up next stgpool
back up TSM database
back up devconfig/volhist
migration

reclamation processing

eject off-site volumes and

insert scratch volumes
expiration processing
clients hours of operations
08:00 18:00

TSM Admin Schedules : Examples

def sched DBBACKUP cmd='backup db devclass=LTOCLASS type=full' t=a active=yes
description='tsm db backup' priority=5 startd=11/10/2011 startt=08:50:00 duration=1 durunits=hours
dayofweek=any EXPiration=Never
Priority : The schedule with the highest priority starts first. If two or more schedules have the same
window start time - For example, a schedule with PRIORITY=3 starts before a schedule with
PRIORITY=5.

update sched DBBACKUP t=a startt=20:30:00

def sched DRM_LTOPOOL cmd='BACKUP STG LTOPOOL Copypool t=a active=yes
description='Offsite movement' priority=5 startd=11/28/2011 startt=16:10:00 duration=5
durunits=hours dayofweek=any EXPiration=Never
Duration : The startup window is the time period during which the schedule must be initiated. If the
schedule must be retried for any reason, the retry attempt must begin before the startup window
elapses, or the operation will not restart.

TSM Admin Schedules

tsm: DLFTSM_PRI>q sched DBBACKUP t=a f=d
Schedule Name: DBBACKUP
Description:
Command: backup db devclass=LTOCLASS3 type=full wait=yes
Priority: 5
Start Date/Time: 07/14/09 11:00:00
Duration: 1 Hour(s)
Schedule Style: Classic
Period: 1 Day(s)
Day of Week: Any
Month:
Day of Month:
Week of Month:
Expiration:
Active?: Yes
Last Update by (administrator): IN063932
Last Update Date/Time: 12/12/11 16:47:55

 TSM maintains backup schedules on the server. These schedules are independent of any given node, and must be
associated with the nodes

Example :
To create a schedule for running an incremental backup at 8:00 PM every day. Name of the schedule 'MY-SCHED
Domain name : MY-DOM [ similar to win / aix ]
Node name : MY-NODE

DEFine SCHedule MY-DOM MY-SCHED startt=20:00

DEFine ASSOCiation MY-DOM MY-SCHED MY-NODE

The define schedule command is used on the TSM server to set up the schedule parameters that will
be used for scheduled client operations. Such operations include backing up or archiving client data
in a specified policy domain.
For example,
Assume the following command is run:
define schedule tsm101 daily_backup starttime=21:00 duration=2 durunits=hours
Domain name : tsm101
Schedule name : daily_backup
Start time : 09:00 pm
Node name : eli
The results are as follows:
Schedule daily backup is defined for policy domain tsm101.
The scheduled action is an incremental backup (default).
The schedule window begins at 9:00 p.m. and has 2 hours to start. The schedule will run every day
(default).
[The startup window is the time period during which the schedule must be initiated. If the schedule
must be retried for any reason, the retry attempt must begin before the startup window elapses, or the
operation will not restart.
The schedule never expires (default).

Client nodes process operations according to the schedules associated with the nodes.
To associate client nodes with a schedule, use the define association command.
A client node can be associated with more than one schedule, and multiple nodes can be
associated to a single schedule.
To associate the eli client node with the daily_backup schedule, both of which belong to the
tsm101 policy domain, enter this command:
define association tsm101 daily_backup eli

tsm: EFLTSM>q sched AIX_PRDDOM ARCHIVE_BIW_00 f=d

Policy Domain Name: AIX_PRDDOM
Schedule Name: ARCHIVE_BIW_00
Description:
Action: Archive
Options: -deletefiles
Objects: /oracle/EBP/oraarch/*
Priority: 5
Start Date/Time: 06/02/10 00:00:00
Duration: 1 Hour(s)
Schedule Style: Classic
Period: 1 Day(s)
Day of Week: Any
Month:
Day of Month:
Week of Month:
Expiration:
Last Update by (administrator): ADMIN
Last Update Date/Time: 06/02/10 13:40:12

Scheduler :
Dsm.sys >> managedservice option : schedule
-Add the following to the system startup file /etc/inittab/
Tsmsched :: once : /usr/bin/dsmc sched > /dev/null 2>&1 # Tsm scheduler
ps -ef|grep dsm

To Verify and to trigger the services on AIX machine:

ps -ef|grep dsm
then give below command
nohup /usr/tivoli/tsm/client/ba/bin/dsmc schedule > /dev/null &
nohup dsmc sched -optfile=path/dsm.opt > /dev/null &

24:00

Backup

Backup

Start

Start

01:00

startup
window

01:00

Startup window: Starttime = 01:00

Function: Action = Incremental Backup
Time between windows: Period = 2 days
Duration = 6 hours

actual
backup
time

Action must start within startup window.

Action may not complete within window.
Scheduled operations run serially on client.
Event log maintained on server.

In defining schedules, date and time can be specified relative to the execution of
the command.

Relative date syntax:

DATE=mm/dd/yyyy
DATE=TODAY
DATE= + number of days
DATE= - number of days

Relative time syntax:

TIME=hh:mm:ss
TIME=NOW
TIME=NOW + number of hours: number of minutes
TIME=NOW - number of hours: number of minutes

define association standard daily_incr client

 Each time an administrator or client node connects with the server, an administrative or client session is
established. These sessions are tracked in the TSM server database.
Each client session is assigned a unique session number. To display information about client sessions, use the
query session command from an administrative client.

Actions from client schedules are recorded as events

Can query events for scheduled and actual start times and end times, and a status
All Activity is logged into the TSM Activity Log
Part of the TSM Database

TSM logs server messages into a database table called the activity log. The log keeps track of many important
messages, such as
incoming client connections,
information about background processes and commands,
scheduled events, and errors that might occur.
The log can be viewed
with the administrative client command query actlog.
Some important parameters can be specified with the query actlog command:

Query actlog begindate=MM/DD/YYYY

This specifies a begin date for the query. When trying to look for errors from
previous days, a begin date is necessary. Values such as today and today-2 can be
used also. The enddate parameter specifies the ending date for the query and
works in the same way.
Query actlog begintime=HH:MM
This specifies a begin time for the query. Values such as now and now-7:00 can
be used also. The endtime parameter specifies the ending time for the query and
works in the same way.
Query actlog search=(search phrase)
This specifies a search phrase to scan on. Only lines containing the phrase will be
returned.

1. Verify that drives are online. If there is a drive in the unavailable state, there may be errors with
schedules.
query drive
2. Verify that database and recovery log volumes are online and synchronized.
query dbvolume
query logvolume
3. Check the status of disk volumes. If any are offline, check for hardware problems.
query volume devclass=disk
4. Check that scratch volumes are available.
query libvolume
5. Check the access state of the tape volumes. For example, a volume that is not in the read-write
state may indicate a problem. You may need to move data and check the volumes out of the
library.
query volume
6. Check database and recovery log statistics.
query db query log
7. Verify that scheduled database backups completed successfully.
query volhistory type=dbbackup
8. Check the activity log for error messages.
query actlog search=ANR????E

Completed
Started
Restarted
In Progress

Failed
Pending
Missed
Future
(?)

Backup completed
Backup in progress
Backup in progress (was restarted)
Usually because Client was rebooted during
backup
May or may not have completed (no
tapes, no drives, etc.)
Backup is waiting to start; still within
window
Backup never started; window has
expired
Backup schedule window not arrived
yet
Backup status unknown

The active version is the most recent backup copy of a file.

Inactive versions are earlier copies of the file.

Inactive Version

When a backup session is performed, and TSM detects that the file has been
deleted from the client, then TSM changes all the backed up versions to
inactive.

Inactive Version

Policies enable data management based on business

requirements by
defining:
Which files are eligible for back up
Which files are eligible for archive
Where the data is stored
How long the data is retained
How many versions are retained
Default is 30 days for backup, 1 year for archive,
default no. of versions is 4

Policy Management
Centrally Managed by Business Policy
Policy Domain 1
Backup Policy
Archive Policy

Policy Domain 2
Backup Policy
Archive Policy

Centrally

Disk pools
Optical pools
Tape pools

Tivoli Storage Manager

Server

defined policies manage

data

What data?
Where to store?
How long to keep

Allow

different types of data to be

treated differently

Domain 1

Domain 2

 You can create multiple domains when there are multiple groups of nodes having similar storage requirements.
For example:
Assume an environment contains a group of user workstations and a group of file servers. With this environment
containing two distinct groups, you would likely
create two separate policy domains such as:
Policy domain WIN-DOM, to which you would assign the workstation nodes
Policy domain UNIX-DOM, to which you would assign the file server nodes

 A policy set is a container of rules for a domain. Although there can be several policy sets in a
domain, only one policy set can be considered active at any particular point.
A domain will only use the policy set named active, which is reserved by TSM.
An administrator must use the validate policyset and activate policyset command to make a policy set
active and available for use.
When activate policyset runs, it verifies that the policy set contains a default management class and
that the copy group definitions specify a valid primary storage pool.

 ** Specifies how files are managed

The management classes contain the backup and archive copy groups.
Every file sent to the TSM server will bind to a management class.
If the class is not specified, files will bind to the default management class and directory information will bind to
the management class that contains the longest retention settings.

 A management class can contain up to two copy groups: one for backups and one for
archives.
Copy groups actually define the rules used to govern the retention of client data.

The backup copy group is concerned with two logical objects: the file and the file copy.

A file is the current data on the client machine.

A file copy is a copy of the file stored in the TSM storage hierarchy. It is also sometimes referred to as a version.

A file copy in TSM can be in one of three states:

Active: The most recent version of a file

Inactive: A previous version of a file
Expired: A file marked for Expiration [ set for purging ]

 Versions will be removed from TSM in the same order in which they were created. The most recent copy will always
be the last copy removed from TSM; the oldest copy will always be the first copy removed from TSM.
The first time a client file is backed up, the file copy will start out
as active because it will be the most current copy. If another backup occurs, the first file copy will change to inactive
and the more recent copy becomes the active copy.

Verexists
Retextra
Verdeleted
Retonly

Copy Group Parameters

The following two parameters in the copy group determine how long each version of the
file is kept, including the last active version:
Verexists specifies the maximum number of versions to maintain, counting both the one
active and variable number of inactive copies.
Retextra specifies the number of days to retain a file copy.
This retention period applies to the number of days that an inactive copy has been marked
inactive.

Copy Group Parameters

Verdeleted specifies the maximum number of file copies to maintain after the file has been deleted /
Moved / renamed.
Retonly specifies the number of days to maintain the last copy of the data (the most recent copy)
after it has been marked inactive.
This number does not apply to other inactive file copies, because they adhere to the retextra value.
The value set for retonly should be greater than or equal to the number of days specified in retextra.

def domain < domain name >

def policyset < domain name > < policyset name >
def mgmnt class < domain name > < policyset name > < mgmtclass name >
Define copygroup type=<archive / backup > <domain name> <policyset> <mgmtclass>
destination=<destination stg pool name> verdataexists=<value> verdeleted=<value>
retextra=<value> retonly=<value>
Activate policyset <domain name> <policy set name>
Validate policyset <domain name> <policy set name>
Update node < node name > domain=< new domain name >
Update the schedules to this node wrt the new domain...

Collocation
In order to reduce no. of sequential devices required we may need to collocate the data.
Collocation need may also arise if we want to avoid reclamation situations.
Collocation types: By node , By Group, By application

Expiration
Versions keep changing states: Active => Inactive => Obsolete
You need to start a process to remove pointers of Obsolete files in Meta Data DB
That process is called as expiration

Reclamation
Once you have expired files from your sequential devices, the space has invalid data.
In order to use the space, you have to move data from one / more sequential devices to
other devices (This is very similar to defragmentation, but as defragmentation does not
work on sequential devices; you have to Move the data)

Collocation - Reduce Restore Time

Collocation is a process in which the

server attempts to keep all files belonging
to a client node on a minimal number of
sequential access storage volumes.

By using collocation, you reduce the

number of volume mount operations
required when users restore or retrieve
many files from the storage pool.

Restore times are usually critical, and

collocation can provide a significant time
saving.

Collocation - Advantages

20

li
fi l

ng

%
30

ng
li li

40

in
if ll
g

Keeps client data together - Reduce tape mounts during restore

Has faster retrieval but less media utilization
Keeps all files together for a node or file system
Can be done at a file system level
Can be done by a group of nodes rather than a single node
Requires more scratch tapes

During expiration processing, older versions of files are expired according to

the rules of the policy domain.
Expiration processing will remove file versions marked for deletion
An active file will never be expired

Expired Version

Expiring data leaves media partially full. Reclamation processing consolidates

data onto fewer new volumes.

Expiring data leaves media partially full. Reclamation processing consolidates

data onto fewer new volumes.

Reclamation Process
Reclamation is a process of consolidating the remaining data from many
sequential access volumes onto fewer new sequential access volumes. Lower
threshold = more tapes; faster reclamation. Higher threshold = fewer tapes,
longer reclamation.
TAPE_SP1

100%

reclamation threshold 60%

Use the RECLAIM STGPOOL command to initiate an automatic drive reclamation

for a sequential access primary or copy storage pool.
Empty tapes move back to scratch or private pools.

Reclaim volumes in
tapepool with at least
30 % reclaimable
space

53.1 % Utilized = 46.9 %

reclaimable space

Reclamation process
starts for tapepool
volume 501154

Input volume is
501154

Output volume
is 002532

Reclamation changes the percent utilized.

Before reclamation:

002532 is 26% utilized

501154 is 53.1% utilized

After reclamation:

002532 is 79.0% utilized

501154 no longer
contains valid data, and
has been deleted from
tapepool

 Movement of data from one pool to another

Usually disk to tape
Configured around high and low thresholds
A storage pool is configured with a target storage pool
i.e.: MY_DISK_POOL MY_TAPE_POOL
Data can be migrated from random to
random or random to sequential devices.
But not from sequential to random devices.
Data Migration can be triggered and stopped using these two values:
High Threshold Value (Default is 90%)
Low Threshold Value (Default is 70%)

 This example assumes that a TSM server has two storage pools: DISKPOOL and
TAPEPOOL.
The QUERY STGPOOL output for these storage pools is displayed in the following
example.

The server determines that the file space \\toddo\c$

for node TODD is consuming the most space in the
disk storage pool. That is, it is consuming more than
any other single backed-up file space and more than
any one client nodes combined archived file spaces.
Therefore, the server chooses to migrate all of
TODDs backed up file spaces.

Because the percent of migratable data has reached or exceeded the high migration
threshold of 70%, the server initiates the migration process by performing the following
tasks :

 After all backed-up files that belong to TODD are migrated to the next storage pool, the server
checks the low migration threshold. Because the low migration threshold has not been reached
(% migratable is now 50; the low migration threshold is 30), the server starts the selection
process again.
In this case, the server determines that the file space /mp3 for node ROBERT is consuming the
most space.
The server therefore chooses to migrate all of the backup file spaces (/usr, /home, and /mp3) for
the node ROBERT.
After all the files for node ROBERT are migrated to TAPEPOOL, the server checks the low
migration threshold again. The low migration threshold is greater than the current % of
migratable data and migration ends.

 MIGDELAY = YES : TSM will take first those files which are taken more space
in file spaces
MIGCONTINUE : TSM migrates files which are existing from longer period

TSM Server

Tape or Disk Library

LAN
(client metadata)

SAN
(client data)

TSM Clients, with the

Storage Agent installed

LAN-free backups and restores use storage area networks (SANs) for data
movement between clients and the server, decreasing the network traffic on the
local area network (LAN). Shared storage resources (disk, tape) are accessible to
both the client and the server over the SAN.

Other useful tips:

Search the online Knowledge Base for matching error messages or problem descriptions
http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
http://publib.boulder.ibm.com/tividd/td/TSMM/SC32-9103-01/en_US/HTML/info_pd.html

 IBM TSM come with three license schema as below:

IBM Tivoli Storage Manager 5.x Basic Version requires tsmbasic.lic license file
IBM Tivoli Storage Manager 5.x Extended Edition requires tsmee.lic license file
IBM Tivoli Storage Manager 5.x Retention Edition requires dataret.lic licesne file.
Note: License cant be mixed at the site level.

Sudhakar Goud