Tim
Open Files can make an issue, especially if you need them - NetBackup does a
good job of most files, but its just the database types (and .pst for that
matter) that it has problems with.

If I can help in anyway, please feel free to ask. One other thing you could
also try is performing a backup not using the all local drives - maybe just
one drive in question. Sometimes doing the "All Local Drives" file selection
can have a negative impact on backup performance.

HTH

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

EADS Astrium Limited, B32AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU

Email: Simon.Weaver at Astrium-eads.net



-----Original Message-----
From: Wilkinson, Tim [mailto:Tim.Wilkinson at dsto.defence.gov.au] 
Sent: 22 June 2006 02:09
To: bob944 at attglobal.net; veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6, Windows, excluding files


No worries - it seems to be a bit of a grey area for most people. I did
research on it a few weeks ago but most of the research has been pushed out
of my head to make room for other stuff.

What I can remember was that S_S (or S_C_C) is supposed to backup DHCP
(amongst a lot of other stuff) and is implied by A_L_D. However, A_L_D also
tried to backup the entire file system of all the drives ('local' drives but
some may not actually be local) on that server. This probably means that
there's some doubling up for some files.

In our environment, we have loads of tape capacity so tend to just back
everything up, just in case. However, open file issues can probably make
some backups very inefficient so we're slowly working out (or at least
trying to) what can be excluded in terms of open files.

Cheers,

Tim
 

-----Original Message-----
From: bob944 [mailto:bob944 at attglobal.net] 
Sent: Thursday, 22 June 2006 10:47 AM
To: Wilkinson, Tim; veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] NBU 6, Windows, excluding files

> Bob - thanks for that; that's a pretty comprehensive answer to my
> questions).

Di nada.  Unfortunately, that may have been 99% of what I know about
Windows.  :-)

> Another question is if you backup A_L_D, which implies SYSTEM_STATE
> (or SHADOW_COPY for Win2k3), if I was to exclude the DHCP db 
> directories, would the policy still get the DHCP backups from S_S 
> (even if S_S is implied in A_L_D, is it actually a separate backup to 
> actual file system backups)? If that was the case then everything that

> gets backed up be S_S could be excluded from A_L_D.

Yep, I'm out of my depth here.  I have no idea how System_State/Shadow Copy
work, nor MS's DHCP and why there isn't an underlying file that can simply
be opened read-only and backed up like any other file.  I try to be as much
a Windows-free zone as possible.  Sorry I can't be any help on this, Tim.


> -----Original Message-----
> From: bob944 [mailto:bob944 at attglobal.net]
> Sent: Wednesday, 21 June 2006 10:39 PM
> To: veritas-bu at mailman.eng.auburn.edu
> Cc: Wilkinson, Tim
> Subject: RE: [Veritas-bu] NBU 6, Windows, excluding files
> 
> > We are backing up some databases (SQL and SharePoint) and
> using agents
> 
> > to backup the actual dbs and also backing up the entire
> systems using
> > ALL_LOCAL_DRIVES.
> > The A_L_D backup jobs meet a few open db files and can't
> back them up
> > (which is expected) and I'm wondering whether I can exclude the
> > directories where the dbs are stored from the policy (which
> is backing
> 
> > up A_L_D) and not affect the agent backups.
> > My guess this is as simply achieved by specifying which policy to
> > exclude from but just want to confirm that this won't
> affect the agent
> > (db) backups.
> 
> No need to make them policy[.sched]-specific; excluding files from a
> filesystem backup has no effect on an agent backup which backs up the 
> data logically:  an exclude_list with /oradata/*dbf won't interfere 
> with the Oracle agent's RMAN backup of the data in those .dbf files.  
> Be clear whether (in this example) the dbf files will not be backed up

> in any filesystem backups or have a specific *clude_list arrangement
> for, say, the prod-ora-cold filesystem backup.
> 
> Exclude directories only if a) they include sufficient other
> useless-to-back-up objects that specifying them is irksome,
> b) there is
> formal agreement that nothing in that directory or its subdirectories 
> will be backed up and c) the data owner has demonstrated that he can 
> recover that application without need of the excluded structure.  (I 
> never trust the DBAs on this.  When you have to recover that critical 
> database/application to new hardware after a disaster and the DBA 
> finds that he really did need setup or control files that he 
> guaranteed you didn't need to back up, it doesn't matter that the 
> error was demonstrably his if the company is out of business because 
> the database is kaput.)
> 
> > What files/folders (on Windows) do people often exclude?
> 
> From memory:
> 
> Any *.mdb, *.ldb, *.edb, ... that are backed up by another means or
> are not necessary to preserve across rebuilds.
> 
> All of the perf*.dat stuff.
> 
> And the default excludes mentioned in the SAG, of course (and ensure
> the system owner knows this).
> 
> Rule:  force backup-and-restore operations to investigate every status

> 1, every single time, determine the files not backed up, go to the
> data/system owner for approval to exclude or ignore, document the 
> process to all.  The annoyance to all concerned usually results in 
> quickly cleaning up all the stat 1 problems.
> 
> 
> 



_______________________________________________
Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

This email is for the intended addressee only.
If you have received it in error then you must not use, retain, disseminate or 
otherwise deal with it.
Please notify the sender by return email.
The views of the author may not necessarily constitute the views of EADS 
Astrium Limited.
Nothing in this email shall bind EADS Astrium Limited in any contract or 
obligation.

EADS Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England