Networker

Re: [Networker] How much browse time for three months?

2004-12-02 11:48:58
Subject: Re: [Networker] How much browse time for three months?
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Thu, 2 Dec 2004 11:51:23 -0500
Okay, I think I see what you're saying -- I mean, it makes sense now
that I think about it -- but I guess I was all wrong, and I wanna be
clear on this.

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.

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.

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? I'm thinking 1 month browse would be
sufficient; so, for example, after the fulls run in first week of April,
I could browse back say 1 month to early March, but since the
incrementals or numerics from that period of March are dependent on the
previous full done in first week of January, all of January and February
would likewise be contained in the index and would be browsable, for a
total of 4 months. HOWEVER, as soon as May rolls around, I could browse
back to April, due to the 1 month browse policy, but going back before
April would not be possible since NetWorker ran a full at beginning of
April, so nothing after that would have any earlier dependencies.
Keeping it 2 months, though, would allow me to go back to March, even
from May, but it also forces all the entries from Jan and Feb to remain
in there. Likewise, when I hit full in July, I still need to go back 1
month to early June, which will be dependent on full from April, so
we're back to 4 months again in index, but as soon as Aug rolls around,
1 month only takes me back to July when full was run so everything
before is no longer needed in index.

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?

George

Darren Dunham wrote:
>
> > For certain groups, I have a schedule that calls for running a level
> > full at the end of the first week of each quarter: Jan, Apr, Jul, Oct
> > and incrementals and level backups at all other times, typically three
> > weeks of incrementals, followed by a lower level backup at the end of
> > the third week like 5, 4, 3, etc. each month until hitting the full
> > again. I never schedule a level backup the week before a full, though,
> > so there might be a strech where there's 4 contiguous weeks of
> > incrementals, followed by the full.
>
> Okay.  So that full is necessary for restoration of data within that
> entire time period (3 months).  Depending on the rate of change in your
> environment, you might consider cloning the full to prevent a bad day if
> a tape fails.
>
> > Can I get by with a 2month browse policy on the clients since I thought
> > it went one cycle beyond that to previous full?
>
> Take the last incremental before a full.  You're specifying that it
> needs to be recoverable 2 months after it was made.  If you do that,
> then not only does it have to be around, but the Full that supports that
> cycle has to be around.  So you'll have about 3 months (total cycle)
> plus 2 months (browse) for a total of 5 months in the indexes.
>
> > At what point does information in the index get truncated? I thought, in
> > this case, it would be at least anything older than 2 months plus one
> > cycle. I want to make sure that fulls are not forced because NetWorker
> > can't figure out how to do an incremental or level since it deleted the
> > previous full info?
>
> It won't delete the previous full until everything that depends on it
> also expires.
>
> --
> 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
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=