ADSM-L

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

2012-04-25 16:17:10
Subject: Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Apr 2012 16:13:01 -0400
No, I will not be running both at the same time.  I will perform the full
DB back as the last task (along with backup devconfig, volhist, etc) and
disconnect old server from the network.

I wonder if I change the IP and hostname on the new server to the same as
the old BEFORE restoring the DB, will it simply see it as the same and not
need the token updated?


Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html



From:   Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   04/25/2012 11:20 AM
Subject:        Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg
Question
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



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.