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

[Prather, Wanda]

The advantage of using EXPORT:

The "frozen" copy of the data  belonging to the old "water" are removed
from the TSM server and tape library.
No new DB entries are created (well, 1, for the export tape), while
moving "water" to a new domain as "ice" means the data and db entries
are recreated when the new "water" backs up again.

The disadvantage of using EXPORT:

You can't access, or view, the frozen data.
The data is out there on a tape, but you can't look at it, or do
anything with it, without doing an IMPORT first (and creating all the DB
entries and taking the tape space on primary volumes).

So which one you use depends on whether realistically need to ever
access the "frozen" data again.

If I were doing the export, FIRST I would do a select on the backups
table for "water", and dump a list of all its files into a flat file.
Retain the flat file so that you at least have a "table of contents" for
what is on the export tape.

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)
  
 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Stapleton, Mark
Sent: Wednesday, March 16, 2005 9:24 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: "Freezing" a node's data - revisiting 'Need to save
permanent cop y of all files currently being stored'


From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On 
Behalf Of Steve Schaub
>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?

My inclination, in this case, would be to create an export tape of the
node(s) in question. Exporting gives the option of either preserving all
copies of all data, or just the active copies.

--
Mark Stapleton ([EMAIL PROTECTED])
Office 262.521.5627

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

[Prather, Wanda]

See responses below:

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? 

>>The simple thing to do:  create the FREEZER domain by making a COPY of
the original domain.
That way all the mgmtclasses will line up properly, you won't get a lot
of TSM whining when expiration runs.
You will have to change ALL the copygroups in the domain to NOLIMIT, but
that's not hard.
Using a copy of the domain is cleaner.
 

Another question - how does this process
affect water's data in the DR copypools?

>>Um.  "water" was renamed to "Ice".
SO "water" now has NO data in the DR copy pools, until you run a BACKUP
STGPOOL.  Then you get a copy of "water"s fresh data in the copy pool
under the name "water".

ALL the old data turned to "Ice" (hee hee) when you did the rename,
files in the copy pool included.
And since you changed the the bu/ar copygroup settings to nolimit, the
copy pool data will never expire either.

Think of the file entries in the TSM DB this way:

  

Every file that is backed up in the primary pool, has a pointer to its
copy in copypool1, a pointer to its copy in copypool2 (if it exists),
all in the same DB record.
If you delete the record for the file in the primary pool, you delete
the copy in the copy pool.

You can't delete the copy pool copy, without also deleting the primary
copy (except by doing a delete volume discarddata=yes on the copy pool
tape volume)  The prmary and copy pool image of the file are permanently
linked together.

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)

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

[Hart, Charles]

Just spoke to our Exchange Admin and he stated he was able to see all the old 
data we "reassociated".  This process came from our Tivoli CE who confirmed 
with Tivoli.  Wish there was an easier way, but it works.

Regards,

Charles 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Steve Schaub
Sent: Wednesday, March 16, 2005 9:38 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: "Freezing" a node's data - revisiting 'Need to save
permanent cop y of all files currently being stored'


Charles,
Were you able to confirm that all of the inactive versions, including ones
of deleted files, rebound correctly, so that nothing expired from that
point?
-steve

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Hart, Charles
Sent: Wednesday, March 16, 2005 9:08 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] "Freezing" a node's data - revisiting 'Need to save
permanent cop y of all files currently being stored'

We had something similar.
1) Created a new domain with all set to Nolimit,
2) Then upd the node to be in that dom.
3) renamed the original node name to something like xxx.old
4) regged a new node name using the orig node name in its orig dom.

Onlly downside is that doing restores prior to the dom/node name change you
have to use vitutal node etc.

Hope this helps

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Steve Schaub
Sent: Wednesday, March 16, 2005 7:11 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

423-752-6574





Please see the following li

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

[Steve Schaub]

Charles,
Were you able to confirm that all of the inactive versions, including ones
of deleted files, rebound correctly, so that nothing expired from that
point?
-steve

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Hart, Charles
Sent: Wednesday, March 16, 2005 9:08 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] "Freezing" a node's data - revisiting 'Need to save
permanent cop y of all files currently being stored'

We had something similar.
1) Created a new domain with all set to Nolimit,
2) Then upd the node to be in that dom.
3) renamed the original node name to something like xxx.old
4) regged a new node name using the orig node name in its orig dom.

Onlly downside is that doing restores prior to the dom/node name change you
have to use vitutal node etc.

Hope this helps

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Steve Schaub
Sent: Wednesday, March 16, 2005 7:11 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

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


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

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

[John Naylor]

Steve,
I presume you don't want to use export
As for expiration,  the Admin Guide states

If a file is bound to a management class that no longer exists, the server
uses the
default management class to manage the backup versions. When the user does
another backup, the server rebinds the file and any backup versions to the
default
management class. If the default management class does not have a backup
copy
group, the server uses the backup retention grace period specified for the
policy
domain.

My reading of this is that the only backups that would not be reboumd
would be inactive versions of deleted files
It would therefore only be the inactive  versions of deletd files that are
problematic.
I am not sure exactly how expiration would work in this case
If it works on a domain exclusive  basis you should be ok, as you can set
the default management class or the grace period to whatever is needed.
It is probably worth your while setting up a small test to see what
happens in this circumstance

John




Steve Schaub <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
16/03/2005 13:11
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@vm.marist.edu
cc

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:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

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

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

[Stapleton, Mark]

From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On 
Behalf Of Steve Schaub
>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?

My inclination, in this case, would be to create an export tape of the
node(s) in question. Exporting gives the option of either preserving all
copies of all data, or just the active copies.

--
Mark Stapleton ([EMAIL PROTECTED])
Office 262.521.5627

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

[Bos, Karel]

Export node?

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: woensdag 16 maart 2005 14:11
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

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

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

[Hart, Charles]

We had something similar.  
1) Created a new domain with all set to Nolimit, 
2) Then upd the node to be in that dom.
3) renamed the original node name to something like xxx.old
4) regged a new node name using the orig node name in its orig dom.  

Onlly downside is that doing restores prior to the dom/node name change you 
have to use vitutal node etc.

Hope this helps

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Steve Schaub
Sent: Wednesday, March 16, 2005 7:11 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

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

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

[Steve Schaub]

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:[EMAIL PROTECTED] On Behalf Of
Lee, Gary D.
Sent: Wednesday, March 16, 2005 7:40 AM
To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf Of
Steve Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

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

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

[Lee, Gary D.]

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:[EMAIL PROTECTED] On Behalf Of Steve 
Schaub
Sent: Tuesday, March 15, 2005 10:35 PM
To: ADSM-L@VM.MARIST.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

[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

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
 

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

[Steve Schaub]

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

[EMAIL PROTECTED] 

423-752-6574





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