OK, just to make things easy and remove potential problem area...
on a different server (say your recovery server) allocate DB, LOG, DBcopy, &
LOGcopy files under the same names & size allocations as exists on your
production server...
If you have an ATL attached and tape drives, it is always nice to have those
device names the same (keeps things simple)
In an AIX env. with 3494ATL & 3590 drives you might have
library /dev/lmcp0
with drives
/dev/rmt1
/dev/rmt2
...
Now say you've installed TSM in this different server... and I mean just a
base install...
nothing more than
dsmserv format 1 /somepath/mytsmlog 1 /somepath/mytsmdb
Now, to recover an environment the main things you need are
log file
db file
dsmserv.opt
dsmserv.dsk
devconfig
volhist (is nice but not absolutely needed)
Oh, and a data base backup tape ;-)
your db & log files, you can create with your straight dsmfmt command...
(here is where IF all your names are alike in both environments, things get
REALLY REALLY EASY !)
ftp from your primary server, over to your recovery server
dsmserv.opt
dsmserv.dsk
devconfig
(now if you set up a recovery environment you will want to do this, say,
daily )
eject your dbbackup tape from the primary server's atl and put it in the
recovery server's atl
dsmserv restore db dev=3590devcblah vol=XXX123 commit=yes
BOOM, you are up and running !
Now, if all your clients are using DNS services, that is IF in your client's
dsm.sys files you have the server entry set like
SErver mytsmserv
TCPServeraddress mytsmserv.myplace.com
all you have to do is have DNS updated with the new IP address and have all
the clients bounce their schedulers
Oh, once the changes have been pushed out through DNS
IF you have hard coded IP addresses in the client's dsm.sys files...
just change the entries to reflect the new address AND bounce the
schedulers...
ANOTHER option is to have a server entry already coded for the "recovery"
server and just alter the reference in the dsm.opt file AND bounce the
scheduler....
AND there are still additional options but you get the drift...
We have used the above methods to move environments around... they work fine
!
later,
Dwight
-----Original Message-----
From: Kevin Zonts [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 10:03 AM
To: [EMAIL PROTECTED]
Subject: Re: Changing the Tivoli server hostname
Dwight,
We are newbies with regards to Tivoli..... Could you briefly explain what
must be done to use a different hostname, or point me to some documentation?
Thanks,
Kevin
"Cook, Dwight E" <[EMAIL PROTECTED]> on 05/30/2001 10:17:19 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Kevin P. Zonts/AMER/UIC)
Subject: Re: Changing the Tivoli server hostname
Sure, done it many times moving servers around...
TSM doesn't care where it is (as long as you stay on the same op sys)
Dwight
-----Original Message-----
From: Kevin Zonts [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 7:14 AM
To: [EMAIL PROTECTED]
Subject: Changing the Tivoli server hostname
Hi All,
Is it possible in the event of a disaster to rebuild the Tivoli server on a
system with a different hostname?
We are implementing our own disaster recovery site and we must use a
different hostname/IP address for the Tivoli server during our testing.
Thanks for your time.
