ADSM-L

Re: Seeking 3.7.5 -> 5.1 upgrade advice..

2002-11-12 12:22:20
Subject: Re: Seeking 3.7.5 -> 5.1 upgrade advice..
From: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 12 Nov 2002 12:28:07 -0500
>    I would really appreciate some advice on how to proceed with an
> upgrade we are planning.
>
> Currently, we are running TSM version 3.7.5 on an Ultra 10/Solaris 7
>
> Our plans are to upgrade to 5.1.x on a Sun Ultra Enterprise 2/Solaris 8.
>
> I am currently trying to figure out if it would be easier to upgrade the
> current 3.7.5 server to 5.1 which will automatically convert everything
> to 5.1 and then move the newly converted database and other needed files
> to the new server which would have 5.1 already installed and running on
> it.
>
> Or, would it be easier to restore the 3.7.5 database from tape to the
> newly configured 5.1 server and run an UPGRADEDB command to bring the
> database up to the current level?
>
> If the second path is the best, does the database have to have the same
> physical path on the disk as the first server?

No, as long as the aggregate size of the installed database volumes on
the new system is sufficient.

> And are the registered nodes, users, volumes and automated commands
> stored in a file which can be easily transferred to the new machine?

Registered nodes and administrative users are stored in the TSM database.
Information on volumes is also stored in the database. However, a TSM
server can and should be configured to save some of the volume information
to one or more flat files whenever the information is updated. Copying
the flat file involved to the new system will make the database restore
much easier. The path to the flat file is given in the server options
file. A similar situation prevails for device definitions. However, you
will probably not be able to simply copy the flat file of device
definitions to the new system; you will probably need to edit the file
to reflect the configuration differences between the two systems.
Automated commands may or may not be in the database, depending on
the exact mechanism used. Scripts and administrative schedules are in
the database, but macros are not. After the database restore is done
you may need to do some clean-up. If the disk storage pool volumes are
different you will need to delete the old ones and define the new ones.
If tape libraries and drives are different you will need to update
the library and drive definitions.

You should probably look at the discussion of server disaster recovery
in the "Administrator's Guide". Server disaster recovery is essentially
an urgent migration to new hardware.

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