Veritas-bu

[Veritas-bu] NBU 6, Windows, excluding files

2006-06-21 20:46:33
Subject: [Veritas-bu] NBU 6, Windows, excluding files
From: bob944 at attglobal.net (bob944)
Date: Wed, 21 Jun 2006 20:46:33 -0400
> 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.
> 
> 
>