And, 
I'd guess that doing MOVE NODEDATA on the source server to make sure you have 
them segregated (preferably into a different pool) would be faster and cleaner 
than server-to-server moves.
 
Probably.   Just another idea.
 
W

________________________________

From: ADSM: Dist Stor Manager on behalf of Allen S. Rout
Sent: Thu 5/17/2007 10:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Server migration



>> On Thu, 17 May 2007 10:56:58 +1000, Steven Harris <steve AT STEVENHARRIS DOT 
>> INFO> said:

> There is no escaping it - the server to server move of each node will
> require a copy from tape to server1 / across to server 2/ back on to
> tape.  The only other option is to just start backing up the nodes to
> the new server and at some point delete them from the old.  There are
> lots of posts on this topic in the archives.


If you are scrupulously careful about making sure no physical media
holds both some data for target server A and some for target server B,
you can just restore the source DB twice, and

 very.

  very.

   very....

carefully delete the "unwanted" nodes from each target server.


- Allen S. Rout