Don't forget to check and update dsmserv.dsk, and so on...
-----Message d'origine-----
De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De la part de
Lawrence Clark
Envoyé : vendredi 18 mai 2007 17:52
À : ADSM-L AT VM.MARIST DOT EDU
Objet : Re: [ADSM-L] Server migration
Yes, it all depends on your situation. If the current on is on SSA you can
export/import the volume groups.
Same if it is on SAN storage.
>>> Pierre.Caye AT ALCATEL-LUCENT DOT FR 05/18/07 12:41 PM >>>
Hi,
There are also other ways,
using disk replication, to duplicate the tsm db You can also look at the
possibilities offers by tsm db mirror/unmirror
Pierre
-----Message d'origine-----
De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De la part de
Steven Harris Envoyé : vendredi 18 mai 2007 03:41 À : ADSM-L AT VM.MARIST DOT
EDU Objet : Re: [ADSM-L] Server migration
Debbie
There is no real need to move data you know.
Set up a second copypool so now you have three copies of everything.
Do your final client backups on the old server, make sure your copypools are
up to date, mark all tapes unavailable. Backup your database
Restore database to TSMA, delete data for all B nodes. Delete all second
copypool volumes then the copypool itself, resume operations
Restore database to TSMB, delete data for all A nodes. Delete all first
copypool volumes then the copypool itself, resume operations, you may like to
reclaim stg at your convenience.
Its a triple somersault without a safety net, but its do-able.
Steve
Haberstroh, Debbie (IT) wrote:
> That's what my plan would be. Hopefully I have enough time to do the moves
> before I need to setup the new server. I am waiting on disk storage for the
> new diskpools before I can start.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf
> Of Prather, Wanda
> Sent: Thursday, May 17, 2007 11:42 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Server migration
>
>
> 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
>
>
>
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain information that is confidential, privileged, and/or otherwise exempt
from disclosure under applicable law. If this electronic message is from an
attorney or someone in the Legal Department, it may also contain confidential
attorney-client communications which may be privileged and protected from
disclosure. If you are not the intended recipient, be advised that you have
received this message in error and that any use, dissemination, forwarding,
printing, or copying is strictly prohibited. Please notify the New York State
Thruway Authority immediately by either responding to this e-mail or calling
(518) 436-2700, and destroy all copies of this message and any attachments.
|