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
|
