Yes, the archive bit is something many used to UNIX systems forget about.
Don't forget what I had in my response to this...
"The only caveat is that if an incremental runs on a class and sees that a
full has never been ran for that class, it will ignore the archive bit and
back up everything. "
This is true and is by design. Even though I am not a big fan of it, it
exists and should be known to avoid issues. Here are two examples of where it
can cause you problems:
1.) a class contains a large number of clients. the clients have been added
on different days of the week and are allowed to do fulls or incrementals any
night of the week. you copy the class to a new class to change the name and
then delete the old class. you have now caused every one of these clients to
do a full on the same night, which could effect your backup window.
2.) you have a client with a large amount of data. because of this you only
allow fulls on the weekend and do incrementals during the week. again, you
change the name of the class by copying it to a new class and deleting the old
one. that night's backup the client will be doing an incremental (uses
incremental retention, etc.), however, it will ignore the archive bit and back
up every file on the system and your backup runs into the next day.
Actually, I would be curious why someone would need two classes with
overlapping file lists? I have clients in more than one class... ie c:\ in
different class than d:\ because the OS has different retention than the rest
of the data, but I don't see why anyone would need the same file lists in more
than one class.
- Scott
Jason Ahrens <AhrensJ AT psi DOT ca>
Sent by: To: "'veritas-bu
AT mailman.eng.auburn DOT edu'"
veritas-bu-admin AT mailman DOT eng. <veritas-bu AT
mailman.eng.auburn DOT edu>
auburn.edu cc:
Subject:
[Veritas-bu] NT/2000 backup strategy and two class
management
10/10/2001 09:53 AM
> -----Original Message-----
> From: Rob Worman [mailto:rob AT worman DOT org]
> Sent: October 5, 2001 08:46
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] cumulative backups
>
>
> nope. An incremental/cumulative schedule defined in class1
> only does its file comparison based on other backups by
> class1. It's as if the other class doesn't exist.
Some of the reading I've done on NetBackup when used on NT is that NetBackup
does in fact use the archive bits on NT/2000. This can cause problems
depending on use (ie: two classes doing full backups, two classes managing
incremental backups, where one of them is not cumulative incrememtal,
etc...)
I may be wrong, I am just going on what I read for the NT/2000 option. Bring
up the Client Properties on a Windows system. By default on the 'Windows
Client' tab, 'Perform incrementals based on archive bit' is turned on.
Turning off this option has other (not so pleasant) ramifications but will
get around the archive bit and two different classes problem on Windows.
By default, a full backup will backup up an entire file system and clear all
the archive bits. When a file is modified, the system is supposed to set the
archive bit again. NetBackup (and pretty much all other Windows based backup
schemes) use the archive bit to know which files to backup for an
incremental. Now, if you do a cumulative incremental, the archive bit is
left on after backup. If you do a differential incremental, the archive bit
is cleared again. A file with a cleared archive bit will not be backed up
until the next full (unless something sets the archive bit once again).
The danger here should be obvious. If two different classes are performing
backups of a Windows systems, and each class is playing with the archive
bits on the file system, the integrity and consistency of both sets of
backup images are suspect for anything except full backups (unless nothing
except full and cumulative incremental backups are done, you cannot use
differential incremental).
Turning off the 'use archive bit' option causes NetBackup to begin looking
at the last modified date to decide if a file should be backed up. This gets
around the archive bit messiness, but if someone resets a modified date, or
moves a file (modified date won't be updated I don't think) or restores a
file from anywhere that keeps the old modified date, NetBackup will not back
up those files again until the next full backup (it thinks it's already on
tape). However, if you are going to have two different classes (or two
different programs, but that's another story altogether) doing backups of a
Windows system, this is your only option to maintain bakup integrity (if
differential incremental backups are involved).
On Unix, this problem is non existant. I beleive NetBackup uses ctime
comparisons, which is much more reliable that last modified time or archive
bit (which don't exist on any Unix I've seen anyway) settings.
Jason
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
