Thank you so much for your detailed (and so far, only!) reply.  You pretty
much hit everything on the head.

A few clarifications to my questions/statements.

Yes, I did mean "default" not "standard", but in my case, "standard" is
the "default", so it applies either way.

7.  How about changing a node to a different, longer retention MC ?  Are
the existing backups/archives rebound to the new longer (or shorter) MC ?

Yes, I meant changing the nodes domain to a different one with a different
set of MC's.

On the issue of importing to a different server that doesn't have a
matching domain/MC, can I assume the rebinding/reassignment take effect
immediately, as you are importing ?  If so, I assume that nothing will
just roll off into the oblivion until we run an EXPIRE INVENTORY, correct
?  For example, if an archive was set for 2-years and we imported it
4-years later and we have long since deleted the domain/MC and the default
is only 2-years, it wouldn't just "not import" it since it has already
expired, would it?  It would import and mark it as expired?
----------------------------------------------------
Zoltan Forray
Virginia Commonwealth University
Office of Technology Services
University Computing Center
e-mail: zforray AT vcu DOT edu
voice: 804-828-4807



"wanda.prather" <wanda.prather AT COMCAST DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/21/2007 04:51 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Questions about retaining data for inactive nodes






Well, I don't see anyone else attacking these questions, so I'll take a
shot.
Here's what i think:

 1. If a node stops performing any backups or does not contact the TSM
server any more, what happens to its backups/archives?  Do the backups
continue to age/expire and roll off (with each Expire Inventory), except
for the ACTIVE copy?  Is this indefinite ?

a) non-active  versions continue to process according to the mgmt class
rules.
  Active versions sit there until somebody does a DELETE FILESPACE,
forever.
b)Yes  (except the rolled off versions will become inaccessible whether
you
run Expire Inventory or not.)
c) yes.

 2.  Do the archives age in the same fashion?, except only based on
date/time ?
 Yes

3.  What if the management class is removed?  Does everything just drop
back to "standard" and thus purge everything faster, if the "standard" is
a lot shorter duration/retention/versions than the original?
Not "standard", but "default".
If "standard" is your Default MC and you remove it, then you have no
default, and Grace Period applies.

4.  What if the node is exported to another TSM server and it does not
have a matching MC?  Back to "standard"?
Back to "Default".  If no Default, then Grace Period.

5.  How about if a node is EXPORTed to tape and then 2-years later,
someone needs something from it and the original server is long gone and
the new server doesn't have any matching MC ?
Back to "Default".  If no "Default", then the files are processed
according
to the Grace Period.

6.  How about on an import and the target server does have a matching MC
but the values are different (e.g. 3-years vs 5-years) ?

The different values take effect immediately.  (If there is anything to
take
effect on - if there is nothing but ACTIVE backup data in what you are
importing, everything stays put.  Remember the mgmt class rules only apply
to non-active backup file versions.)
It's also a good idea to specify RELATIVE when you do an import, so that
non-active versions don't expire at once based on their original age.

7.  How about changing a node to a different, longer retention MC ?  Are
the existing backups/archives rebound to the new longer (or shorter) MC ?

Depends on what you mean.
You can't change a "node" to a different mc, binding occurs at the file
level.

-if you change the retention values of the existing MC/copy groups in the
domain, they take effect immediately.
-if you move the node to a different domain, and it has the same mgmt
class
names, the new values take effect immediately.
-if you move the node to a different domain, and it doesn't have the same
mgmt class names, everything goes to DEFAULT and those rules take effect.
   If no default, the Grace Period takes effect.
-if you put an INCLUDE statement in your dsm.opt to bind backup files to a
different mgmt class:
   Any file you can still run an incremental against will rebind, along
with
it's inactive versions.
   Files you can't run an incremental against because they no longer exist
(or the filesystem isn't mounted), don't rebind.
   Archives never get rebound.

So:
Suppose you have a node with 2 years of backups, and someone says the "L"
word  (litigation! shudder!), and suddenly you get an order that NOTHING
on
that node should be allowed to expire:

1) copy its domain to a domain with a new name like DONTTOUCH
2) Change all the copy group values in that domain to NOLIM NOLIM NOLIM
NOLIM
3) update node VICTIM domain=DONTTOUCH

The files don't have to rebind, because the mgmt class/copy groups are all
the same, but nothing will go away.
Since there is no way to force rebinding of ALL file versions (i.e.,
versions of files that you can't run an incremental of anymore), that's
the
only way I know of to stop ALL file versions from expiring.

THAT should get the discussion going!

Wanda
Just adding to the confusion, a service I gladly provide...




Inquiring users want to know !

----------------------------------------------------
Zoltan Forray
Virginia Commonwealth University
Office of Technology Services
University Computing Center
e-mail: zforray AT vcu DOT edu
voice: 804-828-4807