ADSM-L

Re: "Freezing" a node's data - revisiting 'Need to save permanent cop y of all files currently being stored'

2005-03-16 09:22:03
Subject: Re: "Freezing" a node's data - revisiting 'Need to save permanent cop y of all files currently being stored'
From: "Bos, Karel" <Karel.Bos AT ATOSORIGIN DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 16 Mar 2005 15:21:27 +0100
Export node?

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steve Schaub
Sent: woensdag 16 maart 2005 14:11
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: "Freezing" a node's data - revisiting 'Need to save
permanent cop y of all files currently being stored'

Because the underlying need is to preserve all the backup versions as
they are as of today, not just to take a snapshot of the current data.

Richard also responded to my question, and his point is that my step 3
would not rebind the inactive versions to the new domain, only the
active ones.

So, if I read this correctly, there is no way to stop backup versions
from rolling off?

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] "Freezing" a node's data - revisiting 'Need to
save permanent cop y of all files currently being stored'

Why not just archive the data to management class with retver set to
nolimit?
Seems a whole lot easier.



Gary Lee
Senior System Programmer
Ball State University

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: "Freezing" a node's data - revisiting 'Need to save permanent
cop y of all files currently being stored'

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

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 3/11/2005


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005



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