We use the hosts file to isolate the DR copy and give that system a different 
IP address.

The theory being if the DR TSM server has a different IP then clients cannot 
find it.
If we put bogus host entries in the hosts file the DR TSM server cannot find 
the real TSM servers.  The local IP address in the hosts file on the DR TSM 
server does have to be correct, but it is the new address we gave the system, 
not the production IP.

We also disable schedules in the dsmserv.opt file and do not allow access to 
the production tape libraries.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Chavdar Cholev
Sent: Wednesday, July 31, 2013 10:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] DR tests with multiple TSM servers

Hi Thomas,
I did it before TSM 6.3 with server-to-server with virtual volumes ...but in 
isolated environment and it works.
Now we are migrating to node replication where is very easy to test restore @DR 
location

HTH
Chavdar
On 7/31/2013 18:16, Thomas Denier wrote:
> Until fairly recently my employer has had one production TSM server 
> with a DR plan involving a commercial hot site provider. We now have 
> multiple production servers at multiple locations and a DR plan using 
> our own facilities. We think we understand how recovery from a real 
> disaster would work, but we am having trouble figuring out how to run 
> DR tests in the new environment.
>
> We have two IBM z10 systems in different locations. Each has a Linux 
> image for hosting the production TSM instance or instances for its 
> location. One site has a single TSM instance for storing client data.
> The other site has a client data storage instance, which also serves 
> as a configuration manager for both sites, and a small instance 
> configured as a library manager.
>
> Each site has a primary pool on sequential disk files and a copy pool 
> on tape volumes in a shared tape library at a third location.
>
> We make extensive use of server to server communications. I have 
> already mentioned configuration management and library sharing. We use 
> virtual volumes to send recovery plans between locations and to send 
> library manager database backups to the other location. We have 
> command routing between any pair of servers available for the 
> convenience of the TSM administrators.
>
> Our DR plan involves a standby Linux image at each location. Each 
> standby image will have empty versions of the instance or instances 
> from the other location installed and ready for database restores.
>
> We would like to be able to test the database restore process while 
> all the production instances are active. We are prepared to suspend 
> normal tape activity during DR tests. We would like to be able to run 
> test client restores from the recreated instances.
>
> We are a bit nervous about the idea of two TSM instances on different 
> Linux images with the same server name and with both configured for 
> communications with other servers.
>
> One of the options we are considering is to execute a 'set servername' 
> command as soon as possible after a TSM database restore to eliminate 
> the server name collisions as quickly as possible. We have already 
> thought of several complications that would result from this approach. 
> We would need to execute some 'define server' commands.
> We would need to change the ownership of tape volumes used during 
> tests. In some cases we would need to update a device configuration 
> file to support a TSM database restore using a renamed library manager 
> and then update the library definition in the restored database.
>
> We would appreciate any advice or warnings from TSM administrators who 
> have run DR tests in environments similar to ours.
>
> Thomas Denier
> Thomas Jefferson University Hospital