In regard to: [Networker] Index vs. saveset browse/retention policies, Len...:
Here's the scenario --
Our clients "A" through "W" all have the same browse and retention
policies (5 weeks for both). Clients "X" & "Y" back up to their own unique
pool and have much shorter policies (1 week). However, X & Y's indexes
apparently have the majority's longer policies: The volumes containing X &
Y aren't becoming recyclable when X & Y's savesets expire, but rather when
their indexes expire much later.
For example, here are a couple of lines from mminfo :
volume client name completed browse retent
001703 backup-srv index:X 05/20/09 06/24/09
06/24/09
001703 X C:\ 05/20/09 05/27/09
05/27/09
As you can see, the savesets themselves expire on time, but the indexes
take much longer, therefore holding the volumes non-recyclable. They're
all in X & Y's own pool, BTW. I can only guess this is because the backup
server's client (via which indexes are saved, presumably) is not subject
to X & Ys' policies, but rather the longer ones.
I think that's exactly correct.
Is there something obvious I've overlooked? Can I somehow force X & Y's
indexes to be subject to the shorter policies? Or is this just the way it
is?
Sure, nsrmm will do that for you. Look at the last usage synopsis in the
man page (or PDF docs of the man page, since it appears you may be on
windows). You want the -w and -e options, as well as the saveset ids.
Tim
--
Tim Mooney Tim.Mooney AT ndsu DOT
edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
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
|
