Networker

Re: [Networker] index default browse and retention

2008-03-19 15:45:54
Subject: Re: [Networker] index default browse and retention
From: Davina Treiber <Davina.Treiber AT PEEVRO.CO DOT UK>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 19 Mar 2008 19:41:31 +0000
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