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 rogerd AT uic DOT edu
============ "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:tsmgeek AT HOTMAIL DOT COM]
>Sent: Thursday, August 29, 2002 4:26 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>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
>
|
