OK, if this is a DR scenario, it's a little more complicated. In fact, a lot more complicated. Are both TSM servers at the same location? I wouldn't expect they are if this is for DR. In a disaster, you need to plan for TSM A being unavailable, so you need a way to get your nodes' data to TSM B.... in a basic DR plan this is done by doing a TSM database restore... documented in detail in the Admin Guide. Once that is done, you can restore your clients at the DR site. It sounds, though, like you have two running TSM servers, A and B. Are you trying to have them be a "DR TSM server" for each other? If your hardware is robust enough, you could plan to restore TSM A on the TSM B hardware as a second instance.... so TSM A and B would both run on the same physical server (from the disaster event until the original site is rebuilt). Many of us run this way because of capacity issues... I have five TSM instances on one HP-UX server, sharing a SCSI library.
I guess the bottom line -- the bad news -- is that there is not a way to do exactly what you are describing (AFAIK). TSM B knows nothing about TSM A, or it's nodes or storage pools or volumes. Therefore you can't restore a node which normally belongs to TSM B with data from a corresponding node on TSM A. You can register the target node on TSM A and restore directly, but you cannot count on TSM A being available in the event of a disaster. (I'm thinking while I type) How about this: TSM A at site A, TSM B at site B. All nodes are defined to both TSM A and B. TSM A at site A backs up all of the nodes at site B over the network. (big assumption here that your network can support the traffic) TSM B backs up nodes at site A. Disaster occurs, site A burns to the ground. Restore site A servers to their DR counterparts at site B using their backups on TSM B. Start backing up site B nodes to TSM B. But, you have lost all of site B nodes' existing backups in the fire.... unless you send copy pool volumes offsite. You still need to do a TSM DR database restore to get that history back. Rudimentary at best... Timothy Hughes <[EMAIL PROTECTED] IT.STATE.NJ.US> To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Re: Trying to restore a clients volume (data) from one TSM server to another TSM server 12/11/2006 01:41 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> Robin here's a further explanation. Is there a way to access the TSM backup server for the node (s) that I want the data restored to? There are six 6 nodes the production set on TSM server A and the DR set on TSM server B. The client would like to be able to restore data from one node to it's matching node on TSM server B. Is there a parameter that has to be configured? Thanks again Robin Sharpe wrote: >If all you need to do is a one time restore, I would just register the >target client node (DOCDRB) on TSM server A, perform the restore, them >remove the definition of DOCDRB. > >Regards, >Robin Sharpe >Berlex Labs > > > > Timothy Hughes > <[EMAIL PROTECTED] > IT.STATE.NJ.US> To > Sent by: "ADSM: ADSM-L@VM.MARIST.EDU > Dist Stor cc > Manager" > <[EMAIL PROTECTED] Subject > .EDU> Trying to restore a clients volume > (data) from one TSM server to > another TSM server > 12/11/2006 10:10 > AM > > > Please respond to > "ADSM: Dist Stor > Manager" > <[EMAIL PROTECTED] > .EDU> > > > > > > > A client tried to restore a volume's data ( NVOL1:) from DOCUSRA >to a volume on DOCDRB but can't. DOCUSRA is a node registered >on TSM server A and DOCDRSB is registered on TSM server B does something >needs to be configured for this restore to work? I understand I can restore >data from one node to another on the same TSM server but what >would the syntax be to restore data to another node on another >TSM server? for DR purposes? > >Tim > > >ANS1096S >Either the node does not exist on the server or there is no active >policy set for the node. >Explanation: >This error occurs when you try to access another node's data. Either >the node is not registered with the TSM server, or there is no active >policy set for the node. > > >Thanks in advance for any help or suggestings. > > >TSM 5.3.4.0 >Novell client 5.3.4.0 >AIX 5.3 RS/6000 > >