Client platforms Version Operating system

Tru64 UNIX 5.2 (at 5.1 5.1A

functional
level)
SGI IRIX 5.2 (at 5.1 6.5
functional
level)
IBM NUMA-Q (formerly Sequent) 4.2 IBM NUMA-Q PTX Version 4.5.2

Table 3 gives the PC and other operating systems (non-UNIX) that are supported as clients.
Note that for brevity, only the operating systems supported at the latest Tivoli Storage
Manager server level (5.2 at the time of writing, exceptions where specifically noted) are
shown in this table. Many earlier OS levels are also supported with earlier server levels.
Check the Web site for details.

Table 3 PC and other clients

PC Clients Platforms Version Operating Systems

Novell NetWare 5.2 5.1 or 6 (with current Novell patches)

Microsoft Windows (Intel) 5.2 Windows NT 4.0 with SP5 or SP6a

Windows XP
Windows 2000 Pro, Server, Advanced,
DataCenter (all service packs)
Windows 2003

Apple Macintosh 5.2 Macintosh OS X, V10.1.5 +

OS/400 3.1.2 V4R4, V4R5 - via BRMS API client

Base concepts
This section gives a high level introduction to the base data and storage management
paradigms used by IBM Tivoli Storage Manager to implement its functionality. We will cover
data protection or backup, record retention or archival, storage management, policy, and
security.

Backup and archival concepts

Backup, in IBM Tivoli Storage Manager terms, means the creation of an additional copy of a
data object to be used for operational recovery. As already mentioned, the selection of data
objects to be backed-up needs to be done carefully to ensure that, when restored, the data is
still usable. A data object can be a file, a part of a file, a directory or a user defined data object
like a database table. The backup version of this data object is stored separately in the IBM
Tivoli Storage Manager server storage repository. Potentially, you can make several backup
versions of the data, each version at a different point-in-time. These versions are closely tied
together and related to the original object as a group of backups, and Tivoli Storage Manager
manages the retention of these objects in a consistent way.

If the original data object is corrupted or lost on the client system, restore is the process of
sending a backup version of the data from the server back to the client. Typically, the most
current version of the data is normally restored, so Tivoli Storage Manager selects this as the
default, but you can choose to restore from any of the existing backup versions. The number
and retention period of backup versions is controlled by server policy definitions. Old (extra)

IBM Tivoli Storage Manager: A Technical Introduction 15

 backup versions are automatically deleted as new versions are created, if the number of
versions stored exceeds the defined limit, or may be deleted after a certain period of time.

Figure 6 shows how policy definitions work with Tivoli Storage Manager. In this case, we have
specified to keep a maximum of 6 backup versions of a particular file. The files is backed up
via normal daily backup operations each day that it changes. The most recently backed up file
version is designated the “active” backup. All other versions are “inactive” backups. Tivoli
Storage Manager automatically deletes inactive backups when the total number of backup
versions stored exceeds the policy limit. In this case, on day 8, the oldest inactive file version
(which is actually the file as backed up on day 1) is expired so that at all times, a maximum of
6 backup versions is retained. Tivoli Storage Manager policy definitions also include these
parameters separately for files which are deleted from the client.

Sample Policy:

Retain 5 extra copies plus most recent backup

Version Deleted
ie expired backup
5
Inactive Copy 4
ie previous backups 3
2
Active Copy 1
ie Last backup

File changes
Day 1 2 3 4 5 6 7 8

Figure 6 IBM Tivoli Storage Manager sample policy

For file level based backup, the main difference from many other backup applications is that
Tivoli Storage Manager uses the progressive backup methodology. As shown in Figure 7,
after the first complete backup, IBM Tivoli Storage Manager then operates with incremental
backups only. As a consequence, only those files that are new or that have changed since the
last backup will be backed up.

IBM Tivoli Storage Manager's file level progressive backup methodology, in comparison with
other methods like Full+Incremental or Full+Differential backup schemes, significantly
reduces the amount of data being copied and managed, and prevents unnecessary backups
of unchanged data to reduce and consolidate the recovery tape-set. As a result, IBM Tivoli
Storage Manager offers faster recovery by not restoring multiple versions of the same file,
only the data that is actually needed.

16 IBM Tivoli Storage Manager: A Technical Introduction

 ITSM Standard Standard
Progressive Backup Methodology Incremental Differential

Day 1 10GB 10GB 10GB

1GB 1GB 1GB

Day 2

Day 3 1GB 1GB 2GB

1GB 10GB 10GB

Day 4

Day 5 1GB 1GB 1GB

Day 6 1GB 1GB 2GB

1GB 10GB 10GB

Day 7

Total 16GB Total 34GB Total 36GB

Figure 7 Progressive Backup Methodology vs. other backup schemes

The reorganization of the physical storage media to store each client’s data physically
together on a small number of media — in order to provide faster access in the case of a
complete system recovery — is done transparently to the client, and is completely automated
on the server using data meta information stored in the server database.

IBM Tivoli Storage Manager’s adaptive sub-file backup technology implements another
powerful method to further reduce the amount of data transferred from the client to the server
system. This method enables the backup-archive client (Web client, command line, and GUI)
to back up only the changed portion of a file, either on a byte or block level, instead of
transferring the whole file to the server every time.This feature helps to overcome bandwidth
limitations of the network link, especially for mobile or remote client systems. Figure 8 shows
how this feature works.

IBM Tivoli Storage Manager: A Technical Introduction 17

 Client Machine Master File

+ +

+ + +
Sub Files
Only change bytes or blocks are sent.
Restore requires master file plus sub-files.
Figure 8 Adaptive sub-file backup

At any point in time, IBM Tivoli Storage Manager allows the creation of a complete set of
client files (backup set) on the server system using the most recent backup versions stored in
the server storage repository. Backup sets, as shown in Figure 9, can be used to retain a
snapshot of all client files for a longer period of time (Instant Archive) or for LAN-free recovery
of a client system by copying this backup set onto portable media and restoring them locally
(Rapid Recovery).

18 IBM Tivoli Storage Manager: A Technical Introduction

 Storage Pool Backup Set
Snap shot of active backed up files from one client
Stored and managed as a single object via volume
history
A
A I On specific media or server storage (but not within a
storage pool)
I
A Granularity is file space level

It is not a file system image

tsm> generate backupset

End User
client

A A

Backup SetData Cartridge

IBM QIC-5010

Figure 9 Tivoli Storage Manager Backup set

Archive with IBM Tivoli Storage Manager means creating a copy of a file as a separate object
in the storage repository to be retained for a specific period of time. Typically you would use
this function to create an additional copy of data to be saved for historical purposes, and
therefore, special consideration should be given to ensure that the data format is not
dependent on anything. Vital records (data that must be kept for legal or other business
reasons) are likely candidates for the archive process. You can specify to delete the original
copy of the data on the source system once the archive copy is created on the server. In this
way, you can use archive to make additional space available on the Tivoli Storage Manager
client system. However, archive should not be thought of as a complete space management
function, because transparent automatic recall is not available.

You can gain access to archived data by using retrieve to return it to the Backup/Archive
client. To locate the archived data within the storage repository, Tivoli Storage Manager allows
you to add a description to the data and to form archive packages of related files. You can
then use this description field to search the server database for matching packages, to
determine which data to retrieve.

Therefore, the difference between backup and archive is that backup creates and controls
multiple backup versions that are directly attached to the original client file; whereas archive
creates an additional stored object that is normally kept for a specific period of time, as in the
case of vital records.

Storage and device concepts

All IBM Tivoli Storage Manager-managed client data is stored in the IBM Tivoli Storage
Manager storage repository, which consists of pools of like storage devices, such as disk,
tape, or optical devices. The storage repository is controlled by the server, which uses its own
model of storage to view, classify, and control these storage devices, and to implement the
storage management functionality (see Figure 10).

IBM Tivoli Storage Manager: A Technical Introduction 19

 TSM Client
Storage Repository
WAN, LAN, SAN Storage Pool
Volume

Storage Pool

Storage Pool

Migrate
TSM Server
Copy

Data Objects
Relocate

Storage Pool

Storage Hierarchy

Figure 10 IBM Tivoli Storage Manager storage management concept

The main difference between the storage management approach of IBM Tivoli Storage
Manager and other commonly used systems is that IBM Tivoli Storage Manager storage
management concentrates on managing data objects as they exist in the storage pools,
rather than just the backup tapes as a whole. Data objects can be sub-file components, files,
directories or raw logical volumes that are backed up from the client systems; they can be
objects like tables or records from database applications, or simply a block of data that a
client system wants to store on the server storage. Each object has an associated
management policy “bound” to it which defines what IBM Tivoli Storage Manager does with
that object.

To store these data objects on storage devices and to implement storage management
functions, IBM Tivoli Storage Manager uses logical definitions to classify the available
physical storage resources. Most important is the logical entity called a storage pool which
describes a storage resource for one single type of media; for example, a disk partition or a
set of tape cartridges. Storage pools are the place where data objects are stored.

A storage pool is built up from one or more storage pool volumes. For example, in the case of
a tape storage pool, this would be a single physical tape cartridge. To describe how IBM Tivoli
Storage Manager can access those physical volumes to place the data objects on them, IBM
Tivoli Storage Manager uses a logical entity called a device class. A device class is
connected to a storage pool and specifies how the server gains access to volumes of this
storage pool.

IBM Tivoli Storage Manager organizes storage pools in one or more hierarchical structures.
This storage hierarchy can span over multiple server instances and is used to implement
management functions to migrate data objects, automatically and transparently to the client,
from one storage hierarchy level to another; or in other words, from one storage device to
another. This function may be used, for example, to store backup data (for performance
reasons) onto an IBM Tivoli Storage Manager server disk space before moving the data to
tape cartridges. The actual location of all data objects at all times is automatically tracked
within the server database.

20 IBM Tivoli Storage Manager: A Technical Introduction

IBM Tivoli Storage Manager has implemented additional storage management functions for
moving data objects from one storage volume to another. As discussed in the previous
section, IBM Tivoli Storage Manager uses the progressive backup methodology to back up
client files to the storage repository. Once in the repository, functions are provided within the
server to reorganize data and storage media to facilitate fast and effective recovery. These
Tivoli Storage Manager functions relocate data objects from one volume to another, and
collocate data objects that belong together, either at the client system level or at the data
group level. Collocation is shown in Figure 11.

A B C A B C
A B C A B C
A B C A B C

A B B C C A A B B C C
C A A B A C
B

Collocation Collocation
off on
Figure 11 Tivoli Storage Manager collocation

Another important storage management function implemented within the server is the ability
to copy client data objects (either asynchronously or concurrently with the client backup
operation) and to store them in different storage pools. These copy storage pools can be
created on local tape drives and taken off-site, on remotely accessible tape drives, or on
another server completely. This provides additional copies of the stored data in a secure
place, which is available to be recovered in the event of losing individual storage media or
even the whole storage repository. This function is fully transparent to the client, and is
performed and tracked automatically within the IBM Tivoli Storage Manager server. Figure 12
illustrates the copy storage pool function.

IBM Tivoli Storage Manager: A Technical Introduction 21

 B A
C

C B A C B A
C
B
A

Figure 12 Tivoli Storage Manager copy storage pools

Policy concepts
A data storage management environment consists of three basic types of resources: client
systems, rules, and data. The client systems contain the data to be managed, and the rules
specify how the management must occur; for example, in the case of backup, how many
versions should be kept, where they should be stored, and so on.

IBM Tivoli Storage Manager policies define the relationships between these three resources.
Figure 13 illustrates this policy relationship. Depending on your actual needs for managing
your enterprise data, these policies can be very simple or very complex.

22 IBM Tivoli Storage Manager: A Technical Introduction

 Policy
Policy Domain
Domain
Policy Set Data
Client Nodes Mgmt Class (default)
Backup, Archive and HSM
Data Management Rules

Mgmt Class
Backup, Archive and HSM
Data Management Rules

Mgmt Class

Backup, Archive and HSM

Data Management Rules

Figure 13 Tivoli Storage Manager policy relationships and resources

IBM Tivoli Storage Manager has certain logical entities that group and organize the storage
resources and define relationships between them. Client systems, or nodes in Tivoli Storage
Manager terminology, are grouped together with other nodes with common storage
management requirements, into a Policy Domain.

The Policy Domain contains a logical structure called a Policy Set. A Policy Set contains and
helps to manage a collection of storage management rules for different storage management
activities. The rules are stored, within the Policy Set, in one or more Management Classes. A
Management Class contains the rule descriptions (actually stored in entities called Copy
Groups), which are linked to the stored data objects. The rules are really just a set of storage
management parameters, such as number of stored copies, retention period, storage media,
and so on. When a data object is linked to particular rules, it is said to be “bound” to the
management class that contains those rules.

Another way to look at the components that make up a policy is to consider them in the
hierarchical fashion in which they are defined. Consider the policy domain at the top,
containing at least one policy set which contains many management classes. The
management classes contain the copy groups and the storage management parameters and
it is the management classes that the Tivoli Storage Manager client can use to select how
particular data objects are to be stored.

IBM Tivoli Storage Manager: A Technical Introduction 23

 A Policy Domain contains:
Ê One Active Policy Set, which contains:
– One default Management Class, which contains:
• Some HSM Definitions
• A Backup Copy Group, specifying:
- Where to store data objects
- How many versions to store
- How long to store them
• An Archive Copy Group, specifying:
- Where to store data objects
- How long to store them
– Many other Management Classes, each containing:
• Some HSM Definitions
• A Backup Copy Group
• An Archive Copy Group

A good practice, when designing a Tivoli Storage Manager backup policy, is to consider using
either the number of versions or the retention period. As mentioned above, Tivoli Storage
Manager’s backups are expired based on whichever parameter is matched first (versions or
time) so, in order to achieve a consistent restore capability (that is, restore to one of X
previous versions or restore to any point of backup within Y days) think carefully about the
values you use.

Security concepts
The storage repository of IBM Tivoli Storage Manager is the place where all the data of an
enterprise is stored and managed. Clearly therefore, security is a key aspect of Tivoli Storage
Manager. To ensure that only the owning client or an authorized party can gain access to data
objects, Tivoli Storage Manager implements, for authentication purposes, a mutual suspicion
algorithm, which is similar to the methods used by Kerberos authentication.

Whenever a client (backup/archive or administrative) communicates with the server, an

authentication has to take place. This authentication contains both-sides verification, which
means that the client has to authenticate itself to the server, and the server has to
authenticate itself to the client before any data objects are exchanged.

To do this, all clients have a password and a userid, which is stored at the server side as well
as at the client side. In the authentication dialog these passwords are used to encrypt the
communication. The passwords are not sent over the network, to prevent hackers from
intercepting them, and a new key is used for each encryption. A communication session will
be established only if both sides are able to decrypt the dialog. If the communication has
ended, or if a timeout period without activity is passed, the session will be automatically
terminated and a new authentication will be necessary.

In mobile computing environments, files are often sent to the Tivoli Storage Manager server
system using a modem connection, and so they are exposed to the security hazards of public
telephone lines. The Backup/Archive client optionally provides (in addition to the end-point
security concept outlined above) a data encryption function, which allows for encrypting data
before it is sent to the server, and which protects the data while it is being transferred to the
server and also while it resides in the storage repository.

24 IBM Tivoli Storage Manager: A Technical Introduction