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@VM.MARIST.EDU Subject: Re: Server migration >> On Thu, 17 May 2007 10:56:58 +1000, Steven Harris <[EMAIL PROTECTED]> 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
