.... 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 : [EMAIL PROTECTED] 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. ________________________________________________________________________
