> Wow! That was certainly well explained. You should write documentation
> for Legato ... as extra money, of course.
As long as the archives keep up, I'm happy. Writing documentation is
*much* harder than answering questions.
(We had a recent question about what order Networker uses to pick tapes.
I *know* I had a detailed post about that, but I think it was before
2001 and the beginning of the archives, so I didn't have it any longer.)
> I have 3 related questions to wrap this up.
> 1. We have another two clients (these are in a separate group) that run
> fulls once every 6 months, same schedule with nightly incrementals and
> decrementing monthly numeric backups. However, in this case, automatic
> cloning is turned on for the group, so every save set is cloned. I set
> the browse policy for these two client resources to 6 months, again for
> the wrong reason thinking it was necessary to allow the fulls to be
> spaced out this far, so it looks like what I really have is a situation
> wherein the index could be anywhere from 6 months to 1 year in size and
> anywhere in between depending, but it will always be ay least 6 months.
> But, I really don't need to be able to browse back any further than the
> most recent full, so I'm thinking I can change that browse policy back
> to 1 month and with the schedule the way it is, I will always be able to
> go back to the previous full, and changing the browse policy back to 1
> month will prevent the index from growing beyond 6 months which will
> save a lot of disk space.
..from growing beyond 7 months (browse + cycle). Sounds correct to me.
Note also that the retention policies are on the client, not pool. So
both the original and the clone have the same policy.
> 2. If I change the browse policy on a client to a lower amount, does
> this take effect from that point forward, or will it go back and wipe
> everything prior? I'm thinking it will continue only from there on out
> and will not regress backward, so all older entries will be left alone.
Hmm. I haven't checked recently.
My belief is that 5.x and earlier took effect on existing savesets as
soon as you changed the browse/retention period and then nsrim ran.
With 6.x and later, I think the date for expiration is calculated when
the saveset is run and recorded. So you'd have to go back and change
that date with nsrmm explicitly if you wanted existing savesets to honor
the new period.
> 3. Is there a best or worst time to do this? As long as I make the
> change before anything runs, does it matter?
No, I don't think it matters.
Darren Dunham ddunham AT taos DOT com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu