George,
Yes, we see this when some Windows boxes get large amount of data copied
to them with the archive bit set. Networker does not clear the archive
bit on files like this until a full backup is run. There is some logic
behind it but some may disagree with that.
As others stated, you could invesitgate the NSR_ARCHIVE variable but that
has drawbacks as well.
We've had good luck using the NTFS change journal to address this issue.
The changer journal does have its criteria for backups; it is documented
in the Networker Windows Admin guide I believe. Switching to the change
journal backups we were able to get the incrementals to be a bit more sane.
Robert Maiello
Thomson Healthcare
On Thu, 24 Jun 2004 10:03:36 -0400, George Sinclair
<George.Sinclair AT NOAA DOT GOV> wrote:
>Hi,
>
>We've been noticing that a specific MS NT machine is backing up a large
>quantity of data during incrementals -- much more than we would expect.
>The other thing we've noticed is that the size of the savesets always
>seems to be the same for these incrementals. However, the size of these
>incrementals, while they are bigger than we would think, are still much
>smaller than the fulls, so that's good.
>
>We have 3 client instances for this host. The first instance backs up
>'All' and uses the following custom directive:
>
><< "C:\" >>
>skip: pagefile.sys
>skip: Recycler
>
><< "C:\DIR" >>
>+null: *.*
>
><< "C:\winnt\temp" >>
>+skip: .?* *.*
>
>The next 2 client instances back up various specific paths under C:\DIR
>(e.g. C:\DIR\A-B, C:\DIR\C-F ...) and these are the ones that we've been
>seeing these large incrementals on. Each client instance uses the
>regular directive: 'NT standard directives'. We have scaled back the
>frequency of the fulls on this client, so it's now running fulls every
>other month ... actually, the first week of every third month, but there
>have been some file systems that forced a full prior, probably due to
>the fact that the client index just ran out of space. I have since
>increased it from 2 months browse to 3 months browse, and I'm hoping
>that will resolve that, but still doesn't explain why the incrementals
>are so large in some cases. Should just be backing up everything that's
>changed since the previous backup, so maybe a lot is actually changing?
>Or maybe something is causing the time stamps to change? My MS admin
>tells me that nothing should be changing that much on there, and not
>that much is being added.
>
>Sometime ago, I'd heard on this listing something about how the archive
>bit can get turned on for files on an MS system, or something like that,
>wherein this causes NetWorker to backup the file even though it hasn't
>changed? I might have my terms wrong there, or maybe I'm confused with
>something else. I don't know much about MS, but our MS admin tells me
>that these incrementals should not be that large. We are running virus
>protection software. Could this be causing this?
>
>I just need to get some ideas together so when I sit down with our MS
>pundit, I can tell him what we need to be looking for that might be
>causing this behavior. We just want to make certain that we've checked
>all the "known" causes of this.
>
>We're running 6.1.1 on our server (Solaris 2.8).
>
>Any advice on clues to look for?
>
>Thanks.
>
>George
>
>--
>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.
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
