Tim / Bob
As DHCP runs as a DB (.mdb), by default, it does not get backed up. If an
open file agent is enabled or running, it should capture the file.

HOWEVER, as DHCP does its own internal backup of the DHCP Database, you
should be able to capture this.

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: bob944 [mailto:bob944 at attglobal.net] 
Sent: 22 June 2006 01:47
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