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 <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 02/06/2008 02:59 PM Please respond to "ADSM: Dist Stor Manager" <[email protected]> To [email protected] 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:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Tuesday, February 06, 2007 11:20 AM To: [email protected] 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:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Wednesday, February 06, 2008 10:58 AM To: [email protected] 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.
