All,

I found this thread and it fits a situation I have, where I need to "freeze"
the data that has already been backed up on certain nodes, but new backup
data can be allowed to expire normally.  The following post from Robin Sharp
is exactly what I was considering attempting, except that I want to put the
node back into normal backup after loading it in the "freezer".

Can anyone comment on modifying this procedure by following these steps:
1.    Create a domain called "Freezer" with only one mgmtclass - bu/ar
copygroup settings all at nolimit
2.    upd node water domain=freezer
3.    run an incremental on water to rebind all data to freezer's mgmtclass
4.    rename node water ice
5.    register water, using original settings
6.    run an incremental backup on water, basically a full since it is
considered a "new" node

If I understand TSM's mechanisms, I would then have a node named "ice" that
contains all of "water's" backup data as of a specific point in time, which
will never expire.  I also have "water" with a fresh start.  One question I
have is that with only one mgmtclass in the freezer domain, how much will
TSM complain if I don't go in and change all of the client option sets
pointing to specific mgmtclasses?  Another question - how does this process
affect water's data in the DR copypools?



Original response by Robin Sharp -

Need to save permanent copy of all files currently being stored

Is all that really necessary?

How about creating a new "permanent retention" domain, copy all relevant
policy sets, management classes, copygroups, etc. to the new domain, but
change all retentions to NOLIMIT.  Then move the affected client to the new
domain.  Next incremental should rebind all existing data to the new
"NOLIMIT" management classes.





Steve Schaub, Network Engineer

BlueCross BlueShield of Tennessee

Steve_Schaub AT bcbst DOT com <mailto:Steve_Schaub AT bcbst DOT com>

423-752-6574





Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm