Hello Jeff
It is cumulative in the sense that it backs up all modified data since
the most recent full backup in the same class (at least that's the
defined behaviour). However, with Windows NT and 2000, there's the
concept of the archive bit. If you specify to not use the archive bit
through the client's GUI under configuration, the behaviour will revert
to the comparison of file time stamps same as with the Unix systems
otherwise it will simply back up all modified data as indicated by the
archive bit and not clear the archive bit when done which would mean it
would behave like the defined cumulative but across classes and only if
there aren't differentials also running on the data regardless of class.
I suppose that it may be useful in environments where you only intend to
either use cumulative or differential and would like it to be across
classes.
Your scenario of fulls every two weeks, cumulatives every week and
differentials every day would require you to disable the archive bit use
on each client in order for the class to perform as expected.
Personally, I prefer disabling the archive bit altogether, setting
differentials (or cumulatives) with a one day frequency to one volume
pool, cumulatives to another volume pool and full backups on weekends
with either one, two week, or a month frequency. The idea being that
the differentials and cumulatives will alternate causing every other
day's backups to be on a separate tape from the previous day's backup
(these pools can be in different changers at different locations
depending on available bandwidth for instant automatic offsite). The
loss of any one tape or changer will only mean the resolution of
available restores drops from every day to every other day and hence is
no real loss of data. The full backups can be alternated between the
two pools by setting one schedule with a frequency of say one week while
setting another full backup schedule with a periodicity of two weeks to
the other pool. If the user community wants backups forever, I would
set up two separate classes of just differentials to the respective
volume pools with retentions of infinity, probably at relatively
infrequent intervals i.e..: weekly, monthly or quarterly (note I would
also restrict these classes to one job at a time. This flexibility is
only achieved by disabling the archive bit and only works because
Netbackup will run the schedule with the longer periodicity provided
that the two schedules have the same defined window and are in the same
class (it would be nice if we can have this exclusion across classes
selectively or if there would be the concept of a differential not since
the most recent but second most recent backup).
Note, this alternation of backup target is the whole goal of the old
"Towers of Hanoi" algorithm when used with the classic ten level backups
of Unix systems (re.: Evi Nemeth's "Unix System Administrator's
Handbook"). The idea is to achieve overlapping backups alternating
between media so that a media defect or loss does not result in any
catastrophic impact.
I've tried real hard to think of a reason to use the archive bit but I
can't come up with one. At one point I thought that perhaps robocopy
used the archive bit hence it would be a way of seeding a remote
replicate via tape and doing incremental updates over the net but closer
inspection of robocopy's documentation indicates that it operates solely
on timestamps. I think the fact that the NT/2000 client defaults to
using the archive bit is just a BMD (Bad Management Decision). I can't
believe that comparison of timestamps takes significantly longer than
testing a bit. However, the archive bit usage may be an effort to
emulate the use ctime option on the Unix clients whereby files that are
moved get included in the incrementals but since the ctime option is not
the default for Unix, I fail to see why archive bits would be the
default for NT/2000.
Regards,
John
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu@ENRON
> COMMUNICATIONS On Behalf Of "Jeff Kennedy" <jlkennedy AT amcc DOT com>
> Sent: Wednesday, October 24, 2001 1:14 PM
> To: Anthony Soprano
> Cc: Veritas Mail (E-mail)
> Subject: Re: [Veritas-bu] Request for Scheduling Advice: windows
> NT clients
>
> So, does this mean the cum incr's are truly cumulative? ie. level 1
> backups? I had heard that this was *not* the case and it was a
> misnomer. I hope that I heard incorrectly.
>
> I do fulls once a week (level 0) and cum incr's the rest of the week
> (theoretically this means level 1). So all the changes since the last
> full backup are captured every day, no?
>
> ~JK
>
> Anthony Soprano wrote:
> >
> > Let's say you wanted fulls every 2 weeks, cum incrs every other week
> (in
> > between fulls) , and diff on all other days:
> >
> > Full - frequency = 2 weeks
> > Cum Incr - frequency = 1 week
> > Diff Incr - frequency = 1 day
> >
> > Then set the windows for all these schedules to the same thing, say
> midnight
> > to 9am on all days for all schedules. On day 1 the full is the most
> over
> > due b/c it has the longest period between schedules (2wks), then
> diffs incr
> > will run for 6 days, then you'll get a cum incr on day 8, more diff
> incr for
> > 6 days, then the full again on day 15. rinse and repeat.
> >
> > In the above if you set fulls to once a month, you'll get every
> month: 1
> > full, 3 cum incr and 27 diff incrs, or there abouts. .
> >
> > If you want to do testing on this and other permutations, try using
> hours
> > for frequencies (instead of days/weeks) so you can watch how it
> works all in
> > one day. :) Pick test files so they run quick, and disable catalog
> backups
> > during testing so it does not affect schedule timing if catalog is
> actively
> > getting backed up.
> >
> > A.S.
> >
> > -----Original Message-----
> > From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> > [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of Melinda
> > Orms
> > Sent: Tuesday, October 23, 2001 4:39 PM
> > To: Veritas Mail (E-mail)
> > Subject: [Veritas-bu] Request for Scheduling Advice: windows NT
> clients
> >
> > Hello All,
> >
> > I have previously thought that a cumulative incremental backup would
> > catch everything that has changed since the last successful backup.
> > However a cumulative backup (using the archive bit) is basically
> just a
> > differential that does not clear the archive bit when complete.
> >
> > Does anyone have a suggestion for achieving a schedule that would
> > function as follows:
> >
> > full
> > <-------diff incrs
> > <-----------------cum incr
> > <---------diff incrs
> > <-------------------------------------------------------cum incr
> >
> > ....etc
> >
> > I fill approximately 215 dlt tapes/month with differentials alone.
> > Restores of small directories require several tapes. I would like
> to
> > need only the last full , weekly, and subsequent days' tapes.
> >
> > I appreciate any suggestions on how to manage this and compromises
> that
> > other departments have made to deal with this issue.
> >
> > Advance thanks,
> > Melinda
> >
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> --
> =====================
> Jeff Kennedy
> Unix Administrator
> AMCC
> jlkennedy AT amcc DOT com
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
**********************************************************************
This e-mail is the property of Enron Corp. and/or its relevant affiliate and
may contain confidential and privileged material for the sole use of the
intended recipient (s). Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender or reply to Enron Corp.
at enron.messaging.administration AT enron DOT com and delete all copies of the
message. This e-mail (and any attachments hereto) are not intended to be an
offer (or an acceptance) and do not create or evidence a binding and
enforceable contract between Enron Corp. (or any of its affiliates) and the
intended recipient or any other party, and may not be relied on by anyone as
the basis of a contract by estoppel or otherwise. Thank you.
**********************************************************************
|
