ADSM-L

Changing a node's domain with 'update node ... domain=newdomain'

2004-04-30 11:02:53
Subject: Changing a node's domain with 'update node ... domain=newdomain'
From: Kent Monthei <Kent.J.Monthei AT GSK DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 Apr 2004 10:53:40 -0400
We previously enforced 1 universal retention policy on all our UNIX
clients, so all belong to a single domain.  Now we need to subdivide
existing clients to implement 2 distinct retention policies.
        - for a select few, the original (longer) retention policy still
needs to be enforced
        - for all others, the original retention settings on all
copygroups need to be reduced

The new retention settings are retroactive, i.e. should take effect
immediately and apply to all prior backups for all nodes except the select
few.
Initially we tried management class rebinding (invoked using client
optionsets), but found there's no safe/efficient/straightforward way to
force TSM to rebind old/inactive data from previous backups.
Unfortunately, for the select few nodes remaining on longer retention,
this is precisely the data that we need to preserve & protect.

I just confirmed that nodes can be moved from one domain to another.
Perhaps the simplest way to accomplish this would be:
        1.  use 'copy domain olddomain newdomain' to clone the original
domain, policysets, mgmtclasses, & copygroups
        2.  use 'update node ... domain=newdomain' on the select few
        3.  reduce copygoup retention settings only on the original domain
        4.  let expiration/reclamation do the rest of the work

The Big Q - if the select few are moved to 'newdomain', will expiration
processing apply retention settings from 'newdomain's copygroups to all
backup data for the node, including backups performed when the node was in
the original domain?

- rsvp, thanks

Kent Monthei
GlaxoSmithKline