ADSM-L

Re: [ADSM-L] Recommendations/suggestions for moving a TSM server

2008-02-06 15:23:57
Subject: Re: [ADSM-L] Recommendations/suggestions for moving a TSM server
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 6 Feb 2008 15:23:15 -0500
Thanks for the additional suggestions/methods.

Unfortuantely the old machine does not have any SAN disk (another reason
to get rid of it) nor slots to accomidate another card, so everything is
going to be via tape. In fact, the old box is behind a protected firewall
so to get the devconfig/volhist across will require using a USB drive via
a Windows ssh session.

I guess we will have to downgrade the target server to make sure it is
compatible with the source server.



Andy Huebner <Andy.Huebner AT ALCONLABS DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/06/2008 02:59 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Recommendations/suggestions for moving a TSM server






What we did to upgrade from one AIX 5.1 server to a new AIX 5.3 server
while upgrading TSM from 5.2 to 5.4 was to present a SAN copy of the DB
and logs to the new system.  We did make the mistake of directly
upgrading from 5.2 to 5.4.  You should make a stop at each major level;
IBM can guide you on exact versions.
This method had to advantage of allowing many upgrade tests before the
actual move and the time needed to make the copy was just a few minutes
instead of the hour required to copy a 120GB db to tape and another hour
to get it back off tape.

The basic timeline for us was:
1. Empty old server disk pools (these were left behind)
2. Backup old server DB to tape and write down the number (plan C if it
got ugly)
3. Shutdown old server and copy the DB and log drives using SAN tricks
4. Start new TSM server and upgrade one point version
5. Upgrade TSM and upgrade DB one more time
6. Fix the TSM DB mirrors and storage pool volumes
7. Make sure TSM can see old tapes and restore and backup in that order
8. Swap IPs and names to protect the innocent
9. Go home.

When we were done we had an untouched TSM server turned off and a new
upgraded server.  If it had went bad we could have simply turn the old
server on.

Before the move we did all of the tape drive zoning and installing to
reduce our downtime.


Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: Tuesday, February 06, 2007 11:20 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Recommendations/suggestions for moving a TSM
server

Just think of it as an opportunity for a DR test.

First, TSM does not SUPPORT restoring a TSM DB from a lower level TSM to
a
higher level server.  ("does not support" means they don't test it.  I'm
sure some people have gotten it to work, but the recommended way is
quick
anyway.)

But the recommended procedure is to

1) upgrade your old TSM in place from 5.3 to 5.5.   I haven't done it on
Linux, but on Windows and AIX the 5.3 to 5.5 upgrade is very quick and
straightforward.

2) run a DB backup  (not unload)

3) move your tape drive connections to your new TSM box & configure

4) RESTORE the TSM db to your new box.

5) Switch your IP addresses/DNS alias or whatever so your clients point
to
the new box.

Your DR recovery is complete!

There are other things you can do, like running the backup to disk
instead
of tape if you have SAN connections to the disk, or import the disk with
the
DB to the new system, depending on your hardware config.

But I prefer to do it as a DR drill, if only to give the instructions a
workout.  Especially good exercise if you have junior admins that have
never
done it...



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Wednesday, February 06, 2008 10:58 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Recommendations/suggestions for moving a TSM server

I need to completely replace my old RH3 Linux TSM server (5.3) by moving
the contents to a newer, beefier, RHEL4 box. I also want to upgrade the
server to 5.5.

Of course, the replacement process needs to be completely transparent.
Basically a push-pull.

Can someone point me to docs/references/cookbooks to perform such a
task?

Is a DSMSERV UNLOADDB/LOADFORMAT/RESTOREDB the way to do this?

Currently, the replacement machine is up and fully running with V5.5
server running.


This e-mail (including any attachments) is confidential and may be legally
privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using,
copying or distributing the information in this e-mail or its attachments.
If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete all copies of this message and any
attachments.
Thank you.