ADSM-L

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

2012-04-23 14:27:36
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: Mon, 23 Apr 2012 14:21:15 -0400
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.
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.


Regards,
Shawn
________________________________________________
Shawn Drew





Internet
zforray AT VCU DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
04/23/2012 11:31 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

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






I am having difficulty reconciling which order to do what based on
documentation that says not to do it the way I have/need to do it.  I am
getting ready to do a complete migration from an old 5.5 server (Linux) to
a brand new box (both hardware and OS).

I need to restore the 5.5 DB, volhist, devconfig and dsmserv.opt to the
new box so I can do the conversion to 6.2.3.

Problem is this.............the DB backup will be on an offsite TSM
server, so server-to-server communications is required.

To establish the server-to-server connection from the brand new 5.5
install and the offsite backup server, I need to bring up the new, virgin
5.5 instance and do an "DEFINE SERVER ....  FORCESYNC=YES".

The Administrator Guide section on "Recovering Your Server Using Database
Backups - Restoring a Database to a Point-In-Time" says that after
formatting the log and database files and BEFORE the "dsmserv restore":

"Attention: Do not start the server until after you restore the database
(the next step). Starting the server before the restore would destroy any
existing volume history files."

But since I have to start the new server to define the connection so I can
restore the database........  Or am I simply reading this wrong and they
are assuming the volhist on the machine I am restoring to has the original
volhist (which it wouldn't, at this point).

So, should I simply ignore this and restore the DB and then replace the
volhist/devconfig/dsmserv.opt files on the restored server with the
originals from the server I am replacing/upgrading after I restore the DB
and before performing the upgrade?

As you can tell, this is my first total server upgrade/replacement, so I
am getting anxious about the details/processes/steps.

My current steps are:

Original Server:
1.  Disable client sessions, stop all admin schedules
2.  Empty and delete ALL disk volumes
3.  Backup DB, volhist, devconfig, dsmserv.opt  and HALT server

New Server:
1.  Install 5.5.5.2 - define/format DB volumes
2.  Bring up server and define connection to offsite server with DB backup
3.  Restore DB
4.  Replace volhist, devconfig, dsmserv.opt from backups of original
server
5.  Install 6.2.3
6.  Run /opt/tivoli/tsm/server/bin/dsmupgdx to prepare, convert and insert
5.5 DB into 6.2.3 instance
7.  Change hostname and IP addresses to that of old 5.5 server
8.  Bring up 6.2.3 - redefine disk storage volumes - update server -
forceresync other, library manager servers - update paths

Thoughts, suggestions, ideas, corrections?

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



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.