We are about to do exactly this. Our current Ancient RS/6000 and nearly full ATL P3000 library strains with several thousand nodes, and they are to be replaced by a much faster H80, and a new ATL P7000 library with SuperDLT drives - in a new building a mile away.
Note we selected SuperDLT over LTO or other tape technologies solely because SDLT drives could read our old DLT-IV tape cartridges. An SDLT drive, however, cannot write to a DLT-IV cartridge as I understand it. 1. Synchronize software levels of Operating System and TSM Server between the two systems. This is NOT the time to make any other changes, such as newer software. 2. Build a small test TSM server on the new equipment to debug drivers, device class definitions, etc. and do test backups and restores. 3. Define the new device classes, storage pools, etc. for the new library, on the OLD server, but leave them empty. This is so these definitions will already be in place when the Database is restored from the old server to the new, to shorten the actual cutover. 4. Restore a full database backup from the old server on the new one, and see if it works. Any adjustments needed to make the new device classes etc. work will be replicated back on the old server. Do more test backups and restores on the new server. 5. Meanwhile, back on the old server, set REUSEDELAY to something very long, like 7 days, just to be paranoid. 6. ON A DAY WITH NICE WEATHER: DISABLE SESSIONS; migrate all disk storage pools down to completely empty. Make TWO full database backups of the old server, take one to the new server, restore it, and see if it works. Pack all the tapes in boxes, haul them over to the new location in my car (I don't trust anybody else!), put them in the new library, and set them to READONLY. Some changes discovered in Step 4 may have to be re-done, such as the server name. Until client nodes are allowed to connect to the new server, backout to the old server is still possible, by schlepping all the tapes back to the old location. (PREPARE for Murphy's Law to dictate that it will rain if we need to back out and haul the tapes back to the old site.) 7. Change DNS to point the name the clients have in their dsm.opt files to the new server. This places the new server into production. 8. Gradually, over time, readjust reclamation settings on the new server's old DLT-IV tape storage pools to move the backed-up client data to the new SDLT cartridges, and eject the old DLT-IV cartridges from the new library as they are emptied. This process will probably take several weeks, as fast as possible without interfering with normal backup and restore operations. 9. Declare the old server dead and dismantle it for other uses. (Sorry, the old P3000 library is already spoken for.) This is my plan, with several thousand clients and a relatively short (one-weekend) time window to make the cutover. You'll see here how it goes; our projected cutover is the end of September. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ============ "In theory, theory and practice are the same, ============= ========= but in practice, theory and practice are different." ========= On Thu, 29 Aug 2002, Seay, Paul wrote: >We used export/import successfully, but we only had 23 clients. > >Paul D. Seay, Jr. >Technical Specialist >Naptheon Inc. >757-688-8180 > > >-----Original Message----- >From: TSM geek [mailto:[EMAIL PROTECTED]] >Sent: Thursday, August 29, 2002 4:26 PM >To: [EMAIL PROTECTED] >Subject: Hoping to get new adsm server > > >Hello All, > >We are hoping to get a new server to use for our existing TSM environment. I >was curious if anyone has had any experience in setting up a new TSM server >and migrating the existing TSM environments' data to that new server without >losing any thing? > > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com >
