![]() |
![]() |
TSM is a highly flexible and scalable product that provides the capability for fully managed storage. With TSM's extensive functionality, however, comes a certain amount of complexity. It is important to take the time to learn and understand the TSM approach to storage management. TSM differs from other common storage solutions in several significant ways, including its client/server architecture, progressive backup methodology, and unique data and storage policy objects.
This section provides a high-level overview of the TSM product model, with
an emphasis on its unique features. Table 2 describes the two interrelated discussions that make up the
product model overview.
Table 2. TSM Product Model Overview Topics
Overview topic | Description |
---|---|
Data Management | This section compares the TSM progressive backup methodology with other common approaches. TSM data management policy objects are also described. |
Storage Device and Media Management | This section describes TSM storage policy objects. TSM tape rotation, storage hierarchy, and data migration are also described. The storage pool, a fundamental TSM management object, is described in some detail. |
The main difference between the data management approach of TSM and other commonly used systems is that TSM catalogs and controls data objects instead of simply relying on an operator to manage storage media. Data objects can include:
The way these data objects are handled is defined using data management policies. The use of policy to control data allows TSM to implement its unique backup methodology.
Most backup products offer some variation of the three backup methodologies
described in Table 3.
Table 3. Common Backup Methodologies
Common Backup Methodology | How it Works | Drawbacks |
---|---|---|
Full backup |
|
|
Full + incremental backup |
|
|
Full + differential backup |
|
|
You are probably familiar with one or more of these approaches. Before TSM, managing data required striking a balance between these approaches to achieve the desired level of recoverability and cost efficiency.
A major drawback of these common backup methodologies is that all data is moved on a regular basis, whether it has changed or not. If full backups are performed weekly, every byte of data is moved weekly. In contrast, Tivoli Storage Manager's approach, called Progressive Backup, starts with a full backup, but then moves only changed data from that point on. Another full backup may never be required.
Progressive Backup can be thought of as combining the backup benefits of
the incremental approach with the restore benefits of the differential
approach. Files are backed up incrementally to reduce network traffic,
while recovery media is consolidated to provide better restore
performance. Together with the data management features provided by the
TSM database, the progressive backup methodology reduces the potential for
human error and helps enforce your storage management procedures. Table 4 describes the progressive backup methodology.
Table 4. TSM Progressive Backup Methodology
TSM Backup Methodology | How it Works | Benefits |
---|---|---|
Progressive backup |
|
|
TSM allows for a great deal of flexibility in the implementation of a backup and restore strategy. This allows you to choose a practical configuration that best supports the kinds of recovery scenarios you expect to encounter. Some possible implementations include the following:
In any implementation, the TSM server always knows the location of the most current version of a given file, which reduces search times and improves the recovery process. Refer to the Administrator's Guide for more information.
A TSM environment consists of three basic types of resources: client systems, data, and rules. The client systems generate the data, and the rules specify how that data will be managed. For example, in the case of TSM backup, rules define how many versions of a file should be kept and where they should be stored.
TSM uses policy to define the relationships between these three resource categories. Depending on your needs, TSM policy can be fairly simple or more complex.
TSM policy objects can be divided into two interrelated groups:
One way to begin thinking about TSM data management policy objects is to
look at how they can reflect the organizational structure of your business
environment. Table 5 introduces the TSM data management policy hierarchy, and
provides examples of how you can use these policy objects to achieve your
administrative goals:
Table 5. TSM Data Management Policy
TSM Policy Object | Organizational Unit |
---|---|
Policy Domain | Could map to different categories of TSM client nodes within your
organization.
For example, you might set up different policy domains for UNIX-based file server machines and Windows(R)-based workstations. These domains could be used to provide customized storage management and separate administrative control for each logical group. |
Policy Set | You could use policy sets to create subsets of TSM client nodes within a domain. However, only one policy set can be active within a given policy domain at any time. Because of this restriction, many administrators implement just one policy set and focus their management effort on policy domains, management classes, and copy groups. |
Management Class | Could map to different categories of data generated by your TSM client
nodes. A management class contains one backup copy group, one archive
copy group, or one of each. One management class in a policy set must
be designated as the default. Additional management classes can be
created and specified for use by individual TSM clients.
For example, within the active policy set for the domain created for UNIX(R) server machines, you might set up one management class for general data (default) and one for directory structure information. |
Copy Group | The working elements of TSM policy are defined in copy groups.
These elements include the number of versions of TSM client files to be
maintained and the amount of time those files will be stored. The other
TSM data management policy objects are primarily used to provide
implementation flexibility. There are two kinds of copy groups:
backup and archive.
For example, within the default management class created to handle general data for the UNIX server policy domain, you might set up a backup copy group that maintains three copies of existing data and stores those copies for 100 days. By default, backup data for any TSM client nodes associated with this domain will be managed according to these specifications. |
Figure 1 shows how TSM uses these policy objects to manage client data.
Figure 1. How TSM Controls Backup, Archive, and Space Management
(1) A client backs up, archives, or migrates a file. The file is bound to either the default management class or a management class specified in the client's include-exclude list.
(2) If, according to the management class, the file is eligible for backup, archive, or space management, the client sends the file and file information to the server.
(3) The server checks the management class or copy group to determine where in server storage to store the file initially.
If enough space is not available in the initial storage pool, the server examines the next pool in the hierarchy and places the file there if space is available.
(4) The server stores the file in the appropriate storage pool and stores information about the file in the database.
When files in server storage are migrated from one pool to another, the server updates the associated metadata in the database.
To store and manage data objects on various kinds of storage media and
devices, TSM implements several logical entities to classify the available
storage resources. Table 6 describes the TSM media and device policy set.
Table 6. TSM Storage Device and Media Policy
TSM Policy Object | What it Represents |
---|---|
Volume | Represents one physical or logical unit of storage media.
For example, a volume can represent a tape or a disk partition. Each volume is associated with a single storage pool. |
Storage Pool | Represents a collection of available storage volumes of the same media
type. TSM stores all managed data objects in storage pools.
Storage pools are typically arranged in a hierarchy, with data migrating from
one type of storage to another.
For example, a storage pool with an 8mm tape device class consists of a number of 8mm tape volumes. Clients that need to back up data directly to 8mm tape are associated with this storage pool. Other client data might go first to a DISK storage pool, and then migrate to the 8mm storage pool. Each storage pool is associated with a single device class. |
Device Class | Represents the type of storage device that can use the volumes defined to
a given storage pool.
For example, an 8mm tape device class can be used to associate a storage pool with any library device that handles 8mm tape. Each removable media-type device class is associated with a single library. |
Library | Represents a specific storage device.
For example, a library can represent a standalone drive, a set of standalone drives, a multiple-drive automated device, or a set of drives controlled by an external media manager. |
Drive | Represents a specific physical drive within a storage device.
Each drive is associated with a single library. |
Path | Represents a data and control path from a source to a destination.
To use a library or drive with TSM, a path must be defined between the device and either the TSM server or another designated data mover. |
Data Mover | Represents a SAN-attached device used to transfer TSM client data.
Used only in a TSM server-free data movement or NDMP environment.
For example, a NAS file server with attached storage must be defined as a data mover, so it can transfer client data to and from the storage device as required by the TSM server. |
Disk | Represents SAN-attached disk space owned by a TSM client. Used only in a TSM server-free data movement environment. |
The storage pool is the central element of the TSM storage management environment because it provides the link between TSM data and storage objects. TSM allows you to organize storage pools into one or more hierarchical structures. Each storage hierarchy can span multiple TSM server instances. Storage policy is used to migrate data objects automatically from one storage pool to another. This allows you to initially back up data to fast storage media like disk, and then migrate the data to slower, less expensive media like tape during off-peak hours. Refer to the Administrator's Guide for more information.
By providing policy objects that focus your management effort on data instead of media, TSM can help you fill in the gaps inherent in any tape rotation scheme. Instead of setting up a traditional tape rotation, you set up policy. Tape rotation, as it applies to TSM, can be thought of as the ongoing automated circulation of media through the storage management process. Once TSM selects an available tape, the tape is used and eventually reclaimed according to its associated policy.
Policy-based storage management takes a little time up front to understand and implement, but it allows for a great deal of automation and flexibility. Automating backup and recovery functions reduces the likelihood of human error, and also helps enforce data management goals. Refer to the chapter on managing media in the Administrator's Guide for more information.
Figure 2 summarizes the relationships between the physical device environment, TSM storage management objects, and TSM data management objects.
Figure 2. Putting it All Together
Storage pools are mapped to device classes, which represent devices. The storage pool contains volumes as indicated in the device type associated with the device class. For example, a storage pool that is mapped to a device class with a device type of 8MM contains only 8MM tapes.
All devices require a device class that specifies a device type. Removable media devices also require library and drive definitions, which enable TSM to mount and manage media.
You can define schedules to automate TSM server and client operations. A comprehensive and integrated set of schedules can provide the basis for efficient data management with little need for intervention during normal operations.
To schedule TSM server operations, you only need to create a schedule or set of schedules on the TSM server.
To schedule TSM client operations, you need to do two things:
Any of the following storage management tasks can be automated:
After defining a schedule for a client task, you must specify which clients can use the schedule. This task is called associating clients with schedules. You can associate all the nodes in a given policy domain, or just a subset. Schedule associations can be modified at any time.
To automate client operations, the scheduler component must be installed and configured on each TSM client machine. This is done with a wizard accessed from the backup-archive client graphical interface. The client scheduler runs as a service, which must be started after the scheduler has been configured. Refer to Backup-Archive Installation and User's Guide for more information.