The IBM Tivoli Storage Manager Backup-Archive client provides failover support for various cluster solutions. The TSM Backup-Archive client can be deployed in other cluster environments to provide at least a minimum level of backup protection. This article delineates between failover support and standard backup support in environments in which we do not provide a failover solution for backup. Tip: Beginning with Version 7.1.3, IBM Tivoli Storage Manager is now IBM Spectrum Protect™. Some applications such as the software fulfillment systems and IBM License Metric Tool use the new product name. However, the software and its product documentation continue to use the Tivoli Storage Manager product name. To learn more about the rebranding transition, see http://www.ibm.com/support/docview.wss?uid=swg21963634.
A cluster is simply a disk with a physical connection to two or more computers. Clustering software basically marshals logical access to these disks; in most cluster architectures this means the software only allows one machine physical access to the device at a time. For the machine that currently has access a cluster drive, the cluster drive is in no way distinguishable from a local drive. Clustering software does not provide any new file system support but instead relies on traditional file systems. For example, HACMP allows clustering over JFS file systems. MSCS and VCS in the Windows environment rely on the NTFS and FAT file systems.
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.
Was this topic helpful?
17 June 2018