IBM Tivoli Storage Manager statement of support - using the Tivoli Storage Manager Backup-Archive client in unsupported cluster environments

Resolving The Problem

Failover support in the context of TSM backup is the ability to manage a logical cluster disk as one filespace on the TSM server, as opposed to several filespaces on one of many nodes that can have access to the cluster resource. For example, today ldisk1 is local to machine-a; tomorrow the same ldisk1 is local to machine-b due to a failover. Failover support in TSM is the ability to recognize that although ldisk1 is now owned by machine-b, it must be treated as the same entity as the ldisk1 that was local to machine-a yesterday. Without this support, TSM would backup ldisk1 from machine-a, and then when ldisk1 failed to machine-b, it would be backed-up again as a separate filespace on the TSM server. This presents two problems. First, data is backed-up to the TSM server redundantly. Secondly, in the event of a restore of the entire disk, it would be very difficult to determine from where the files should be restored, i.e., which files should be restored from machine-a and which from machine-b.

Another aspect of failover support in the context of the TSM server is management of TSM server passwords. Two machines cannot simply share the same TSM server password in order to act as if they were the same machine. If a user stores a TSM server password on shared storage, the information to decrypt the information from the local disk would differ between the two machines. If each machine kept its own local copy of the password, one of the machines would eventually update its copy of the local password (e.g., if the TSM server instructed it to do so due to a password expiration period) and there is no mechanism to notify the other machine in such an event.

The failover support in the TSM Backup-Archive client solves the filespace management issue and the TSM server password management issue. If a user has deployed the TSM B-A client in an unsupported cluster environment, we cannot provide solutions to these two problems. Users in these environments can still backup and restore data from a cluster drive as if it were just another local disk drive, just without the benefits of these management features.

Problems we cannot address in unsupported cluster environments:

· After a failover, the TSM Backup-Archive backs-up a new copy of the data to a different filespace on the TSM server.
· The TSM Backup-Archive was processing a backup operation and a failover occurred; after the failover the TSM backup operation did not restart on the other cluster node.
· I am trying to setup two machines with the same TSM NODENAME and instruct TSM to store the TSM server password on shared storage; after I login to the TSM server from one machine I am prompted on the other machine if I try to login to the TSM server.
· I am trying to setup two machines with the same TSM NODENAME and instruct TSM to store the TSM server password on each machine; this works for awhile but last night my schedule didn't run because it had prompted for a TSM server password.
· I am trying to restore data from a cluster disk and I have the data stored on two different filesystems on the TSM server; can't I tell TSM to automatically restore the correct versions of the files?

Customers who are experiencing such problems should be directed to open a requirement for the correct backup-archive client cluster support.

Problems that do not have to do with a failover, the affects of a failover, or a password issue are probably not related to our clustering solution but rather to the underlying file system. If the underlying file system is supported by the TSM Backup-Archive client, the problem should be diagnosed outside the context of clustering.