ADSM-L

Re: Move Nodes to another ADSM server

1998-11-19 10:51:23
Subject: Re: Move Nodes to another ADSM server
From: bbullock <bbullock AT MICRON DOT COM>
Date: Thu, 19 Nov 1998 08:51:23 -0700
I too will be splitting up 2 very large domains onto 2 servers. My thoughts
are the same:

migrate the primary disk pools to tape pools.
make a full backup of the db.
restore the database to the new server.
Rename the new server, redefine the scratch & private categories, delete
the unwanted schedules on both servers.
repoint the clients to the new adsm server.
Checkout the primary storagepool tapes belonging to the new server's nodes
and make them unavailable on the old server.
Checkin those same tapes into the new server and make them available.
Gradually delete the unneeded filespaces off the old server.

The copypool will be a mess since the data from both domains are spread
across the tapes. I think I will just re-create the copypool on the new
server and as I delete filespaces on the old server, those tape will
gradually be reclaimed. Sure, I will need a bunch more tapes during this
transition, but better to have too may copies of the data during a change
like this than not enough.


-----Original Message-----
Hi Jack,
Hi Jack,

I am also going to move some nodes from Server_A to a new server_B (both
are AIX server). In my case, the 2nd server is new and both servers are
using common media 3590; in general, I plan to backup db from old server_A,
restore db to server_B, delete the filespace, node ... etc of those I don't
want to keep in Server_A, and delete the rest from Server_B. Depends on the
data volume of those nodes, seems that this can prevent export/import which
might take a long time when compare to delete filespace.

I hope the above will work but still have to sort out the details for the
move, eg, network path connectivity between new server and client, disk
space for database restore, disable the server or lock the node to prevent
user access, checkout tapes from Server_A and checkin tapes to Server_B ...
etc.

Regards,
Eric Tang