Quick and dirty answer - the risk is *between 0 and 100* and cannot be evaluated *exactly* ! If there is no failover during the month the risk is certainly 0. In case of failover or failback during the backup window the risk is ~= 100. And can either you or your customer forget for while about backups and just explain which resource is where at specific time after several failovers and failbacks? The configuration your described is somewhat messy and the main question goes in cluster configuration direction and aside from TSM/backup. Lets assume we have a good cluster configuration (other people here called it "supported"). Lets catch the bull horns and go direct to five systems with machines M1-M5, local resources LR1-LR5 and cluster resources CR1-CR4 (or even CR5, it does not change the things): - create dsm.sys for M1-M4 containing server/node stanzas for nodes LR1+CR1, ... , LR4 + CR4 - create dsm.sys for M5 containing stanzas for LR5+CR1+CR2+CR3+CR4 - create dsmLR<x>.opt for each M1-M5 in a local (non-shared) resource and use it to start OS&cluster binaries - create dsmCR<n>.opt for each CR1-CR4 in a shared filesystem accessible after failover/failback - configure on OS start the startup of LR<x> TSM client scheduler using dsmLR<x>.opt - configure on primary nodes boot startup of cluster TSM client schedule using CR<n>.opt - ensure failover/failback scripts stop the cluster resource TSM client scheduler on the failing server and consecutive startup of this scheduler on the new active node (in your case it would be always M<n> - M5 or M5 - M<n>). Trigger new incremental backup immeditely after failover/failback to secure interrupted backup during failover. - ensure correct domain statements in each stanza Using something similar the risk can be estimated - it is close to the risk of backing up an ordinary server. The increased server availability due to clustering does not lower backup risk, it lowers downtime risk. And this might be used not only for all-fail-over-one but even for any-fail-anywhere cluster. So do it by the book and you will go the paved road, do it as you wish and enjoy the jungle. If nobody used this before none could evaluated it.
Zlatko Krastev IT Consultant "Warren, Matthew James" <[EMAIL PROTECTED]> on 21.01.2002 14:22:43 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: versioning / expiring / multiple backups under same nodename We know the correct way to be backing up the cluster. The customer did not implement it this way, but we are recommending them to do so. Before they switch from their current set-up to how we are recommending they backup the cluster (With 2 TSM environments on each machine, one for local disk, the other for shared disk) they would like to know exactly what risk they are runing with their current setup. Matt. -----Original Message----- From: Mike Yager [mailto:[EMAIL PROTECTED]] Sent: Friday, January 18, 2002 4:27 PM To: [EMAIL PROTECTED] Subject: Re: versioning / expiring / multiple backups under same nodename Exactly, while im not doing TSM on my clusters (yet) Daniel is correct. In my MS-clustered environment, I have the following entries in DNS SRV01 SRV02 CLUSTER1 DB2-01 the last 2 are a "logical" name of the cluster resource. This allows the "resource" to be managed separately from the physical machine or other "resources" and/or physical machine. I would caution you to be careful as you indicated the resources DO show up as being owned by the controlling node. IE DON'T back it up via that attachment even if you can see it as when it changes to a new node you will have a different name as you mentioned.... Please keep us posted as I'll be headed down this road shortly. -mike ?-- The description you gave tells me there is something wrong with your configuration. Normally when you set up TSM to handle clustering, you have one TSM nodename for each clusternode(M1,M2,M3). These nodenames are only for backing up local files on the node. Then you have either one nodename for each clusterresource, or one nodename for all clusterresources. You also have to bind the nodename to the clusterresource, so that the TSM service that handles the cluster nodename, moves with the clusterresource. --------------------------------------------- Michael Yager IBM Global Services (919)382-4808
