ADSM-L

Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question

2012-04-25 11:23:54
Subject: Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question
From: Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Apr 2012 11:19:25 -0400
The server definitions exist in the devconfig along with any other devices
you might want to store your database backup.   You shouldn't have to
redefine it on the new server.

If you are testing with server-server, starting up the restored server in
the same server-network while the old one is still running could mess with
the current server registrations/passwords.  You might have to run some
"update server xx forcesync=yes" commands if you run into authentication
issues after you test.


Something I might try..   Build the new server with an empty database and
new server name.  Configure all the server-server communications, backup
the devconfig then halt.
Use the devconfig output and copy the lines with the new server
definitions.  edit the devconfig file you are bringing over with the db
backup and insert these lines (replacing the older server definitions)

I would still look for an alternate way to store your DB backup.  Maybe an
NFS share or something.

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
asr AT UFL DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
04/25/2012 10:46 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question






On 04/23/2012 02:21 PM, Shawn Drew wrote:
> Why wouldn't you use tape for the DB backup/restore.  Seems like that
> would be faster and easier than using a remote server-server connection.

My reason for that was thus:  In order to let the new server access the
tapes for DB restore, I must let the new server access the tapes. :)   I
didn't want to let that happen at all, at all; so I stuck the backup on
media which I could offer the new server without endangering the 'old'
(i.e. still live production) server.


> Another option is just halting TSM and rsyncing the db/log volumes over
to
> the new location, assuming it is the same path on the new server.

Works for the final exercise, but not for testing.

- Allen S. Rout



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.