ADSM-L

Re: [ADSM-L] TSM server move to new hardware

2009-10-29 09:39:27
Subject: Re: [ADSM-L] TSM server move to new hardware
From: Howard Coles <Howard.Coles AT ARDENTHEALTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 29 Oct 2009 08:36:26 -0500
Make sure of two things:
1.  You setup your new server with the same hostname and IP address as
the last one (which you've already thought of)
2.  You import the LUNs in the right order on the new box.  That is, if
you're like us and have multiple LUNs making up the same logical volume.

Other than that I think you're plan will work. :-D  

I would do a full DB backup just before you shut down the old one, just
in case.   I would also empty, and remove the disk storage pool volumes,
just to remove one more thing going wrong.  You can always recreate
them.

See Ya'
Howard

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Keith Arbogast
> Sent: Wednesday, October 28, 2009 2:47 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] TSM server move to new hardware
> 
> I am moving a TSM 5.5.3.0 server running on RHEL 4 to new server
> hardware and RHEL 5.  Same TSM server version.   In the end, I would
> like to be able to bring up the new server with the same TSM server
> identity as the old.
> 
> In order to accomplish this, our plan is to disconnect the LUNs which
> contain the database, log files and storage pools from the old
> physical server and connect them to the new physical server.  We are
> planning on accomplishing this by copying the original devconfig,
> volhistory, dsmserv.dsk, and dsmserv.opt  files to the
/opt/tivoli/tsm/
> server/bin  directory on the new RHEL 5 server.  Once these files have
> been copied and are in place we will then start dsmserv and set
> servername=<original TSM server name>.
> 
> We will also disconnect the 3584 tape library from the old server and
> connect it to the new one.
> 
> Will this re-create the original TSM server on the new hardware and
> RHEL build without the need to do a database restore, or am I
> forgetting something essential that will make this move more
> complicated than I have described?
> 
> Please let me know.
> 
> Best wishes,
> Keith Arbogast
> Indiana University

<Prev in Thread] Current Thread [Next in Thread>