I also agree that resetting the individual save set retention and browse
period will work fine in most cases but I can see that being an issue in a
large environment as you could be talking about thousands of save sets. As
for as deleting savesets that haven't reached their expiration date I would
have to question why they were on the same tape with savesets that have a
shorter retention period. That being said I agree with you if you are mixing
savesets with varying retention periods on the same tapes then deleting the
tapes will not work 
 
Michael Nored
Consultant
Nored Consulting, LLC
 
M: (407) 399-8162
T:  (352) 350-7142
E: mnored AT Netzero DOT net


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Davina Treiber
Sent: Wednesday, March 19, 2008 3:42 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] index default browse and retention

Michael Nored wrote:
> David,
> I see you have received a number of suggestions methods to handle this
> issue, I would like to add one more.
> 
> You can use one client configuration attached to any number of groups
> provided you want the browse period to equal the longest retention. In
your
> example add the client to a daily group that writes to a daily pool, add
the
> same client to the weekly group which writes to its own pool, and do the
> same for the monthly. Since you have now isolated your daily, weekly and
> monthly backups to their own pool it is fairly simple to run a mminfo
query
> to identify tapes in you daily and weekly pools which have a last access
> date greater that the retention period you really want for them. I.E if
you
> want to retain your daily backups for 1 week then query the daily pool for
> tapes that have a last access date greater than 8 days. Use the output of
> the mminfo to recycle the tapes older than a week, one caveat here is that
> the last access date gets updated when a tape is opened for a read
function
> such as restores, If you script the mminfo and recycle then run it daily I
> think you will get what your looking for.

I don't agree. The first part is fine, but the idea of a script 
recycling tapes based on last access is wrong for NetWorker. In some 
cases this will result in deleting backups that are still within the 
desired retention period, and in the worst case making some data 
unrecoverable. You need to let NetWorker expire save sets based on its 
dependencies otherwise you can run into a lot of trouble.

If you are going to post-process with a script (which I was trying to 
avoid suggesting), then there are a couple of better options that will 
work in conjunction with your scheme:

(1) Run a daily script to select all save sets in the daily and weekly 
pools and shorten their browse and retention.

(2) Initially write all save sets with a short browse policy (which 
matches your shortest retention in use) but then use a daily script to 
extend the browse time of weekly and monthly backups to match their 
retention.

The second option should actually be quite easy to write, since there 
are no calculations to do to decide on the new browse or retention 
period - you just take the retention time and apply the same time to the 
browse time using nsrmm.

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER