.... I am hoping I will be able to run a
db backup on the current system and restore to the new system
>>Yep, that is what you'll do.
... (I'm assuming I will need to delete and redefine drives, library,
paths and
storage pools once 'Server1' is started on the new system?).
>>Yep.
Has anybody carried out a similar task and if so can you offer any
advice on the best way to migrate from our current setup to the new? I
>>I've done this many times. Works like a charm.
..will be installing TSM (5.2.2.4) to the new server today or tomorrow -
our current db volume is on the local D: drive but will live on the E:
drive of the new server - will it be possible to restore to E:?
>>Yes, TSM won't care where your new DB lives.
.. Should I use 'dsmfmt -db' and 'dsmfmt -log' to create the
appropriate volumes?
>>That's the thing you MUST do. On your new TSM server, you must have a
DB and recovery log defined AT LEAST AS LARGE as your old one before you
can restore the DB.
... A friend has suggested creating a new devc of 'file', running a db
backup
to use this devc and then copying the backup across to the new server to
use for the db restore rather than trying to mount a tape in the new
library - would this be possible?
>>That will work, too. But it shouldn't be a problem getting a tape
mounted in your new library, if you've defined and tested it. I think
it is a good idea to make sure the hardware works, before you try to do
the DB restore. (Just run a DB backup of your new, almost-empty DB to
tape as a test.)
I would be very grateful for any advice or suggestions, many thanks.
>>
1) MAKE SURE that before you run your last DB backup on the old system,
you update all your disk storage pools to highmig=0 and lowmig=0, get
all the data pushed out to tape (because those disk storage pools are
going bye-bye.)
2) Don't bother creating the storage pools on your new system until
AFTER you reload the DB. When you reload the DB, TSM will see the OLD
definitions of the storage pools, pointing to the old disk volumes, and
will give you a bunch of errors because it can't find them. So you will
end up deleting the old disk storage pools and creating new ones,
anyway.
3) When you set up the library definition on your new system, create a
COPY of your devconfig file and save it under a new name. Because when
you reload the TSM db, again it picks up the OLD library definitions
(paths, addresses, etc.). It won't know about the new library. You
will either have to update it's path, or delete and redefine it. You
will definitlely need to delete and redefine the drives, because they
will have new serial#. For me, it's easier to copy the commands out of
the devconfig copy, than to figure them out again. If you end up using
a new library name, you have to check all your tapes in to the new
library.
4) The DB restore will take probably 3 times as long as it takes to
backup. But you will see its progress in the DOS window where the DB
restore is running, so don't be distressed.
Can't think of anything else at the moment. It's actually a pretty fun
exercise! Write down all the steps you do, and when you're done you
have a disaster recovery plan!
Wanda Prather
"I/O, I/O, It's all about I/O" -(me)
E-Mail : copperfield.adams AT wwavrc.co DOT uk
This e-mail and any files transmitted with it are confidential and
intended solely for the individual or entity to whom they are addressed.
Any views or opinions presented or expressed are those of the
author(s) and may not necessarily represent those of the Company or of
any WWAV Rapp Collins Group Company and no representation is
given nor liability accepted for the accuracy or completeness of any
information contained in this email unless expressly stated to the
contrary.
If you are not the intended recipient or have received this e-mail in
error, you may not use, disseminate, forward, print or copy it, but
please notify the sender that you have received it in error.
Whilst we have taken reasonable precautions to ensure that any
attachment to this e-mail has been swept for viruses, we cannot accept
liability for any damage sustained as a result of software viruses and
would advise that you carry out your own virus checks before opening
any attachment. Please note that communications sent by or to any
person through our computer systems may be viewed by other
company personnel and agents.
Registered Office: 1 Riverside, Manbre Road, London W6 9WA
________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs.
________________________________________________________________________
|
