Are you sure we don't work for the same bunch of clowns.... I've been 
banging heads with management over this type of issue for ages, they just 
don't understand backups (or restores).

Don't create the exclued list for this purpose, you'll be creating and 
administrative nightmare that everyone will eventually blame you for.

Maybe your "management" could purchase some OTM licenses or if you're on a 
later version you could look at the VSS settings.

Sometimes stuff just happens, in that case look at what is being skipped, if 
it's the same files left open by the same users educate them also.  Maybe 
its a SQL agent issue,  you'd better not exlude the DB's :-)

Good luck, it's hard to win an arguement with the boss when all he's 
interested in is the green area in the graph.

Chris.



>From: Ed Wilts <ewilts AT ewilts DOT org>
>To: "Lewick, Taylor" <tlewick AT hrblock DOT com>
>CC: Jennifer Hooper <jennifer.hooper AT peregrine DOT com>,   
>veritas-bu AT mailman.eng.auburn DOT edu
>Subject: Re: [Veritas-bu] Excluding Files for Successful Jobs
>Date: Fri, 7 Jan 2005 14:12:34 -0600
>
>On Fri, Jan 07, 2005 at 12:54:15PM -0600, Lewick, Taylor wrote:
> > The bigger issue here sounds like you need to educate management.  You
> > may want to explain to them that you don't want to always exclude files
> > that are causing status 1s.  They may just be open at that time, and
> > sometimes during the backup a process may not be using/opening those
> > files, so you may actually get a good backup of that file from time to
> > time.
>
>Another thing to realize that may be open today, but not tomorrow.  If
>you exclude the file because the user had it open today, you'll punish
>him by not backing up the file tomorrow.  The only to ensure that you
>will never have a status 1 is to open the file for exclusive access.  I
>don't believe that will go over well with management though.
>
>My philosophy is that if I exclude a file, I for sure won't have
>anything to recover.  If I restore a file that was open at the time the
>backup was done, I most likely will get something useful, and something
>is almost always better than nothing.
>
>This doesn't mean you should always ignore status 1s because you
>shouldn't.  You may be trying to back up SQL databases that you really
>should skip and deal with separately.  In the majority of cases, though,
>a status 1 is perfectly acceptable.
>
> > This sounds like a management request along the lines of, "Fine, green,
> > yellow, red is great, but I only want to see green".
>
>Then get off the road.  Sometimes the traffic lights are yellow :-)
>
>         .../Ed
>
>--
>Ed Wilts, Mounds View, MN, USA
>mailto:ewilts AT ewilts DOT org
>_______________________________________________
>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu