ADSM-L

Re: Merging two Client Nodes to one new Client Node

1998-09-24 16:38:21
Subject: Re: Merging two Client Nodes to one new Client Node
From: Dan Giles <Dan_Giles AT MANULIFE DOT COM>
Date: Thu, 24 Sep 1998 16:38:21 -0400
Dwight,
The REPLACEDEFS refers to the node definitions, not the file spaces. Here's
what the manual says:

Replacedefs= value
Specifies whether node definitions that exist on the server should be
replaced by
imported objects having the same name. Existing file spaces are not
replaced.
New file spaces are created when identical file space names are
encountered.
The default value is NO. Possible values are:

So, it looks like
rename node1 to node3
export node3
delete node3
rename node2 to node3
import node3 (from step 2)
rename the filespaces to what they will actually look like on node3

Dan Giles
Application Specialist
Manulife Financial, Corporate
Phone: 416-926-3549 Fax: 416-926-5234





From: Dwight Cook <decook AT AMOCO DOT COM> on 09/23/98 07:37 PM GMT

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: ADSM)
Subject:  Re: Merging two Client Nodes to one new Client Node




     I have been working on moving our clients of MVS ADSM servers over to
     AIX ADSM servers...  due to 3490's on mvs and 3590's on AIX (back in
     the early planning but now we have 3590's on MVS) we focused on using
     server to server communications to perform this task... it is working
     fine I might add...
     Anyway with the IMPORT, even if the client doesn't exist on the new
     server, the IMPORT operation will rename each file space as it is
     processed (this is done by changing the last char to a 1 or adding a 1
     onto the end of the filespace name)  The import does allow you to
     specify REPLACEDEFS=YES which will import the file spaces by their
     existing name (and sounds like it will dust existing bkup/arch files)
     rather than rename them...
     So far I've been able to wait on a client to complete a routine
     incremental, then export the data to a virtual volume on the
     destination server, import the node & its data from the virtual volume
     on the receiving server (using the replacedef=yes), and have the new
     server ready to run prior to the next regularly scheduled incremental
     backup.  (and the initial incremental of the client on the new adsm
     server went as expected and only backed up the changed files)
     I am getting to the point where I don't think a clean move can run in
     under 20 hours (client's with multiple terabytes of adsm data) so I'm
     looking at running an export with filedata=backupactive importing that
     to the new adsm server keeping the file names, then performing a full
     export of all backup&archive data and performing that import with the
     rename feature.  This way I'll have a clean cut-off date for archives
     and fairly clean with backups (and by fairly clean I mean the only
     dirty part will be active files at the time of exp/imp will reside
     under both the origional filespace name and the renamed filespace
     name)since the renamed file spaces don't really exist on the client
     that data won't change and should be treated (maybe) as deleted data
     thus falls under the "backup data versions deleted" parameter of the
     backup copy group and will eventually go away.

     Anyway... this has me to where I think I'll see if an import with
     replacedef=yes simply smokes the existing data, replacing it with the
     import's data or if it tries to merge the two (the later not thought
     to be the case due to the words REPLACEDEF=YES...
     replace D.N.E. merge)
     anyway,
            later,
                  Dwight



______________________________ Reply Separator
_________________________________
Subject: Re: Merging two Client Nodes to one new Client Node
Author:  Luci.Ziebart (Luci_Ziebart AT MGIC DOT COM) at unix,mime
Date:    9/23/98 10:18 AM


Thanks Dan,  Just want to clarify.. If I am consolidating two small servers
to
one large server, I would just rename the nodes and filespaces to the new
server
for both.   Just to complicate matters, what if the servers have like
filenames
that I am consolidating.  How will ADSM treat these files?  Should I
archive
these files?




Dan Giles <Dan_Giles AT MANULIFE DOT COM> on 09/22/98 11:09:00 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Luci Ziebart)
Subject:  Re: Merging two Client Nodes to one new Client Node




Luci,

There is know way of doing this. We are doing a lot of server consolidation
here, so this little trick would be quite useful.

All you can do is pick the larger of the old servers and rename the node
name to the new server. Rename filespaces as appropriate. The data from the
old server will just have to get backed up again.

There may be another way using export/import, but I've never tried it. It's
success depends on whether or not ADSM will merge the imported data with an
existing node. If someone can answer this question, it would be
appreciated.

Dan Giles
Application Specialist
Manulife Financial, Corporate
Phone: 416-926-3549 Fax: 416-926-5234





From: Luci Ziebart <Luci_Ziebart AT MGIC DOT COM> on 09/18/98 06:34 PM GMT

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: ADSM)
Subject:  Merging two Client Nodes to one new Client Node




We are in the process of merging the two Unix clients on to one new Unix
client.
Still want ADSM to maintain the archives and backups for the two old
clients.

Would I just use the rename node and rename filespace for each of the old
nodes?
I'm concerned, since there is no mention of what will happen if you rename
more
that 1 node to the same node in the ADSM manuals.  Our server is MVS.

Thanks