On Thu, Jan 05, 2006 at 12:18:51PM -0500, Paul Keating wrote:
> Using Ed's case as an example.....why not put /var/tmp on a separate
> mount point and backup without the "cross mount points" directive??
Because the server is backed up with an ALL_LOCAL_FILES directive. We
could add the mount point to an exclude list but then we're back to
where we started. This means that I have to create a special policy for
this server and specify all the mount points separately. That adds
both management overhead and risk.
.../Ed
> > -----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
> > Mark.Donaldson AT cexp DOT com
> > Sent: January 5, 2006 12:14 PM
> > To: veritas-bu AT mailman.eng.auburn DOT edu
> > Subject: Re: [Veritas-bu] Exclude then search or vice-versa?
> >
> >
> > A copy for the list - seems like an issue that we'd all be
> > interested in. A
> > reply from a Symantec employee is below, Ed & my replies are
> > below that.
> >
> > -----Original Message-----
> > From: Steven Cashman
> > To: Ed Wilts; Mark Donaldson
> > Subject: RE: [Veritas-bu] Exclude then search or vice-versa?
> >
> >
> > Ed and Mark
> >
> > Question - Does NB, to anybody's knowledge, build a list of
> > all changed
> > files then apply the exclusion rule or does it do the opposite.
> >
> > Answer - From my Exp its neither, it never builds a complete
> > list of all
> > changed files. But maybe little of both
> >
> > NBU uses a MS call (on windows) to get a starting file / folder. This
> > structure is read and each file is compared against our
> > exclude list. If
> > the file / folder is set to be backed up (archive bit set)
> > and the file
> > is not in the exclude list it is backed up. We then move onto the next
> > file / folder and repeat the process.
> >
> > So even when you exclude a large sub directory from backups NBU still
> > has to scan each file under that dir to see if it should back it up. I
> > would not consider this a bug because you can exclude /parent/sub1 yet
> > put an include in the same policy for /parent/sub1/exec/ So NBU has to
> > scan each file / folder and compare it against our include
> > and exclude.
> > If NBU was changed to not scan a directory when it meet a
> > parent exclude
> > this would not be possible.
> >
> > The only thing I can think of is trying to move the folders with many
> > small files to another drive so they can be backed up that way.
> >
> > Hope that helps
> >
> >
> > ....to which Ed replied:
> > -----Original Message-----
> >
> > Thanks for the explanation Steve. Here's my problem though, and I'm
> > guessing that Mark's is similar.
> >
> > RWare, a commercial product, creates hundreds of thousands of small
> > (mostly empty) files in /var/tmp on Solaris. I need to backup /var
> > which should take well under an hour. Because of all of the files in
> > /var/tmp, the backup takes well over 16 hours even though I'm
> > excluding
> > /var/tmp. Obviously I'm taking a hit on the client doing the
> > comparison and wasting resources. How can I speed this backup up?
> >
> > Thanks again,
> > .../Ed
> >
> > ....and I countered....
> > -----Original Message-----
> >
> > My product is Documentum but the concept is right on. Our
> > Docbase is huge,
> > growing fast, and fits the millions of small files profile.
> >
> > I have no include list for this policy. The contents of /parent are
> > variable but I always want to exclude backing up
> > /parent/sub1. Backing up
> > an open Docbase for Documentum is of no value - this size of
> > docbase has to
> > be done cold. Both Master & Client are Unix (The same
> > server, in fact).
> >
> > A workaround I can I can see is to specify, for my example,
> > the /parent/sub3
> > directly in the filelist for the policy and not sub1 & sub2.
> > The problem
> > is, of course, that files located directly in /parent won't
> > be backed up (A
> > problem for Ed's "/var" situation) and now I've got a real maintenance
> > problem whenever the contents of /parent change at all.
> >
> > Another work-around would be to not backup the entire
> > filesystem, opting for
> > a script generated list of items to be backed up, followed in
> > the end by a
> > user-backup. Fulls & incrementals become manually defined.
> > This would be a
> > major hassle, of course, and subverts the reason to buy any enterprise
> > backup product.
> >
> > A partial "fix" to this would be to prevent the scan of
> > excluded directories
> > if there's no applicable include file for the backup. In my
> > experience, the
> > use of an include file is pretty rare so this might be an effective
> > optimazation. In the event an include file exists, then do
> > the subdir scan
> > & compare as required.
> >
> > -M
> >
> > ...and that's all there is so far...
> > _______________________________________________
> > 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
--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts AT ewilts DOT org
|