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 <Steve_Schaub AT bcbst DOT com>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
16/03/2005 13:11
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: "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
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy Group.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission. Unless specifically stated otherwise, this email (or
any attachments to it) is not an offer capable of acceptance or acceptance of
an offer and it does not form part of a binding contractual agreement.
Scottish Hydro-Electric, Southern Electric, SWALEC, S+S and SSE Power
Distribution are trading names of the Scottish and Southern Energy Group.
**********************************************************************
|
