> 1 month browse policy was always standard on our clients, but I was
> running fulls at the end of every month. When I then decided to spread
> the fulls further apart for certain less critical machines, I changed
> the browse time on them from 1 month to 2 months but ONLY because I was
> somehow under the impression that in order for NetWorker to be able to
> space those fulls two months apart -- well, really 9 weeks -- and still
> be able to run incrementals and numeric backups in the interim, it would
> be necessary to have the browse time set accordingly, but it appears
> that these are mutually exclusive to some extent and that what really
> determines things is the schedule you've set.
Correct. If your full backup takes 30+ hours, over 20 tapes, and drags
the host down due to poor performance, you don't want Networker suddenly
scheduling one of those when you don't expect it!
(Even so, it will if the full can't be found at all)
> NetWorker will use the schedule, and will still be able to perform
> 'incr' and numerics as long as the previous full is still in the index.
> And there's no reason it wouldn't be unless someone removed it and/or
> recycled a volume which I don't do before it's a least 6 months old.
> It's not as if NetWorker is gonna say well gee, the browse policy is
> only 2 months so I'm gonna just drop everything I know about from before
> then; it goes according to the schedule.
Right. The browse policy and retention policy are applied to
savesets/volumes, but overriding those policies are the following
#1 The current (most recent) cycle is not automatically purged.
#2 Ancestors are not purged while dependencies to them exist.
You have to manually purge or expire to override those points.
> So there's no reason to have those browse policies set to 2 months since
> I'm getting 3 months of browse by default anyway since I'm spacing the
> fulls 3 months apart, right?
The browse policy sets a lower limit. Sometimes you're getting 5 months
now, sometimes you're getting 2.
If you need to go back 2 months, don't set the policy to 1.
When the last incr in a cycle is almost 2 months old, it's holding the
cycle in place, and the oldest data is about 5 months old. After the
last incr passes the policy window, the data for the cycle is purged or
expired. Your oldest data is now about 2 months old.
minimum = browse/retention window (how far back can I always go?)
maximum = minimum + cycle period (how much disk space do I need?)
> So the important point I wanna make sure I'm clear on is that in this
> case, 1 month browse will always allow me to recover files 1 month old
> -- never mind the fact that there will be times when I can go back
> further, but only due to the dependency factor -- and setting this
> browse policy to 1 month will not affect NetWorker's ability to space
> the fulls 9 weeks apart.
> Would there ever be a reason to have a browse policy longer than the
> time between fulls if all you ever cared about was being able to recover
> only back to last full?
As long as the full was recoverable, no.
If your cycles are very far apart, you're putting a big dependency on
that first full. It may be worth it to clone that piece. Likewise if
you have a long uncloned 'incr' chain, early failures lead to lot of
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