1. Please help support our sponsors by considering their products and services.
    Our sponsors enable us to maintain high-speed Internet connection and fast webservers.
    They support this free information and knowledge exchange forum service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions

Move node data, migration scenario

Discussion in 'Backup / Archive Discussion' started by [email protected], Jan 5, 2017.

  1. bjorn.zakrisson@atea.com

    [email protected] ADSM.ORG Member

    Nov 13, 2007
    Likes Received:
    Hi all.
    Best way to move/migrate Nodes to new domain/policy sets/mgmt classes and new naming standards for customer Nodes.

    We are moving our customer to a new SP 7.1.7 server with a complete redesigned domain/policy structure.
    The customer wants the existing data to be placed on the server where they are migrated to.

    We have set up Node replication for "migrating" the data to Directory pool.
    But we want to use the new domain/policy structure.

    What is the right way to do it? Node replication, move node to new domain, move node data to new domian, change node name on Node.

    Or should a use "export" command? Can i export node and node data directly to new policydomain and rebind mgmt classes on node?

    Im a bit confused here.. So some input from experts would be nice

  3. marclant

    marclant ADSM.ORG Moderator

    Jun 16, 2006
    Likes Received:
    Accelerated Value Specialist for Spectrum Protect
    Only the node and the management classes belong to a domain, the actual data just belongs to a node and stored in storage pool.

    You have two options. Move the nodes to the new domain before migration if the pool destination will be different on the new server. Or after if the pools are the same.

    When you import a node, it goes in the same domain. So you need to either change the node to a new domain before the export on the source or after the import on the target. So, regardless if you do export or replication, same thing applies for your nodes, you have to either put them in the new domain on the original server, or after the fact on the target server.

    There is no rebind taking place. However, all the data will expire according to the management class the node belongs to at the time expiration runs. So if you have NODE1 in DOMAIN1 and have objects bound to management class DEFAULT, MC1 and MC2. And you update the node to belong to DOMAIN2, but it only has DEFAULT and MC1. All the objects that are bound to DEFAULT and MC1 now have the retention of those management classes in DOMAIN2. Because MC2 doesn't exist in DOMAIN2, those will remain bound to MC2, but will use the retention of the default management class because it doesn't exist. If you later create a MC2, from that point forward, they will use that management class.

    Your best bet is probably on the source before you do anything is to create all the new domains on the source. You can even use the COPY DOMAIN command to create the new domains based on an existing one as it will copy all the management classes too.

    Once you have all your new domains, with the right management classes and all the right copy groups with destination and retention, then you can start updating nodes to use the new domain. When you replicate or export, which ever way you want, all the domain info will follow automatically.

    You also have the option to do all the domain changes after the migration to the new server. There's no right or wrong.

Share This Page