Eight Top Tips for a Successful IBM Tivoli Storage Manager Implementation

Abstract
This Tip discusses important recommendations when implementing an enterprise storage
solution with IBM Tivoli Storage Manager. IBM Tivoli Storage Manager is the number one
product of choice to accomplish an efficient and effective enterprise wide storage solution in
many companies. IBM Tivoli Storage Manager is a very powerful tool with lots of flavors and
colors, bells and whistles, features and functions, so to a certain degree, it is complex. This
expert advice may save time and frustration as you plan your IBM Tivoli Storage Manager
implementation. Note: Detailed information will be provided in the IBM Redbooks, SG24-4877-
03 and SG24-5416-02.

Contents
1. Embrace progressive incremental backup paradigm

The architecture of IBM Tivoli Storage Manager and its progressive incremental backup paradigm is
unique. It is very important to understand and use this powerful method.

A misunderstanding would probably lead to implementing traditional backup strategies that include weekly
“full” backups even though little has changed, represented by selective backups in IBM Tivoli Storage
Manager. Furthermore, this type of thinking leads to too much backed up data and, therefore, more IBM
Tivoli Storage Manager database objects than needed. This will increase the database unnecessarily and
decreases the IBM Tivoli Storage Manager performance.

More backup data than necessary leads to more tape usage than what is actually required. This will
unnecessarily burden and/or complicate tape management processes and tape vaulting.

2. Learn about IBM Tivoli Storage Manager functionality

Common sense dictates that it is important to understand a product’s functionality in order to use it
optimally. Especially for storage management products like IBM Tivoli Storage Manager, you need to
know what the different implemented commands effect.

It is important to understand the differences between backup and archive to not misuse these functions
for each other.

IBM Tivoli Storage Manager includes some powerful functions for disaster recovery management
including tape vaulting. Needless to say, these tape volumes for disaster recovery should be taken offsite
and not be left onsite. Another common mistake is to overwork your backups - this happens when you
simply back up or archive everything on a system. You should outline your requirements for restore,
retrieve, and even disaster recovery. This will define the data that actually has to be backed up.
3. Leverage IBM Tivoli Storage Manager functionality

Misunderstanding of functionality often leads to misuse of functionality. Even though IBM Tivoli Storage
Manager offers a lot of functions and features, it is recommended not to overuse them. All to often, an
IBM Tivoli Storage Manager implementation contains too many definitions for domains, schedules,
storage pools, or device classes. This complicates administration and operation. Knowing what your
deliverable is will help you plan the end result better.

Collocation, for example, is an expedient feature; but if it is used on all tape volumes, it will waste tapes.
Collocation will direct all data of a client onto the same tape whenever possible, even if there are minimal
amounts of data to back up. Large volume tapes such as LTO, can have huge amounts of unused space
if collocation is used too liberally. Moreover, migration from disk to tape will extraordinarily increase tape
mounts, which may decelerate data processing. The same applies for direct backup to tape. Direct
backup to tape is only recommended when streaming a lot of continuous data, so the tape drive doesn’t
have to rewind and reposition its read head incessantly.

Most IT environments include some special data processing applications like databases or mail servers.
IBM Tivoli Storage Manager offers additional data protection modules to support backup procedures for
these kinds of applications. It is highly recommended to use these Data Protection modules and not
misuse the common backup/archive client for these special data operations.

4. Carefully estimate backup performance

Performance depends on various factors, including the IBM Tivoli Storage Manager server and client
hardware, network, attached storage devices, operating systems, etc. When calculating the actual data
processing performance, each system included in the storage management environment should be
treated separately, or even in groups of similar system types. Don’t assume the same performance for
every single system.

As long as there is not a dedicated network for backup purposes, the actual network bandwidth is shared
between different systems with different applications. For performance and time window calculations, the
real available network bandwidth has to be figured out. Even when using separate networks, there are
factors that decrease the theoretical network bandwidth, such as protocol overhead.

File level backup performance heavily depends on the current storage device hardware, protocol,
attachment and file system type. Assuming that all files will be processed at the same speed will therefore
lead to a wrong calculation result.

5. Carefully estimate restore performance

The performance considerations for backup also match for restores. Since most restore requests will be
processed through a tape device, there are some additional factors that have to be regarded, like robotics
and tape mount delays, device read speed, and position delays.

6. Test restore in production situations

The area of backup and archive in an enterprise storage management environment is implemented for
one express aim: Restore! In case of a failure of whatever kind, you want to be able to restore all your lost
data. Therefore it is advisable not only to test the individual implementation, but to test it in a production
environment.

Most test scenarios are only organized under lab conditions, not real world situations. This could lead to
the wrong assumption that your restore procedures will work in case of failures. In complex environments,
data relationships between different systems or applications will also have to be considered. In case of
failure, a mis-oriented or mis-ordered restore sequence would lead to an inconsistent data environment.

Restore can cover a huge area of scenarios from single file up to bare metal restore. Disaster recovery
strategies and methods have to be well considered, implemented, documented, and tested.

Furthermore, all procedures regardless of backup or restore should be documented and revised regularly
so their validity is ensured.

7. Train staff prior to implementation

IBM Tivoli Storage Manager is a powerful and complex product that can be very helpful when it is
implemented and used by well-trained staff. Therefore, it is highly recommended that the responsible
personnel should be educated in IBM Tivoli Storage Manager products before using them in a production
environment.

Skills in how to install common software under specific operating systems, and even knowledge about
other backup products, will not suffice. Hasty implementations will lead to wasted money, wasted time,
frustration, and even data loss, not to mention poor performance by the product.

8. Schedule and monitor daily housekeeping activities

Once IBM Tivoli Storage Manager is implemented and set up, it has to be operated and managed. Poor
data and storage management practices will compromise your business data. Even after executing
backups; the data, and therefore IBM Tivoli Storage Manager, has to be administered. Some processes,
such as tape vaulting, are daily processes that your business relies on in case of a disaster.