On Wednesday 16 July 2003 02:16, Zoltan Forray/AC/VCU wrote:
> I am doing some reorganization and want to moving a node to a different
> Policy Domain.
>
> What are the ramifications of this ?   Any gotchas ?  Pitfalls ?

This is easy to do, but requires a bit of planning to avoid unexpected
results. The issue is whether the management classes currently used by the
client exist in the new policy domain, and how the data is retained in the
new domain.

Assume your client is using the following management classes in the current
policy domain:

MC1 = The default class, contains both a backup and archive copygroup
           (exists in both policy domains)

MC2 = Contains both a backup and archive copygroup
           (only exists in the original policy domain)

MC3 = Contains both a backup and archive copygroup
           (exists in both policy domains, but without the archive CG in the
             new policy domain)

When you move the client to the new domain, several things can happen:

1/ If an identically named MC exists, data will be retained by that MC
    (eg. MC1 -> MC1)

2/ If the identically named MC *does not* exist, data will be rebound to the
default MC (whatever that happens to be...)
    (eg. MC2 -> MC1)

So the risk so far is just that the data will be rebound, and you need to
check things like retention periods, versions retained, stgpool destinations
(LAN/SAN), etc.

And then there is the case that:

3/ If an identically named MC exists, but it lacks either a backup or archive
copygroup (which exists in the original), and the server *already* has that
type of data, the data will be retained by that MC *but* it won't know how
long to retain the existing data. This data is then retained by the "Grace"
backup and/or archive retention periods set at the policy domain level. Also,
new backups or archives sent from your client may fail, as the MC can't store
that type of data.
    (eg. MC3 -> MC3 + grace retention for existing data)

So, check that your MC's exist in both domains, but more importantly check
that the relevant copygroups exist.

You'll also want to check things like actual retention values, stgpool
destinations (and data paths, LAN/SAN), and client schedules (and associated
client daemons).

If you separate your stgpools by policy domain, you may also want to move the
existing data between pools (using "move nodedata").

Easy. :)

Regards,
Steven P.

--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group

Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907
Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia
http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au