I think that Jeff has
the right idea here. Building an exclude list for things that cause a
status 1 can be very helpful to you if you are in a S-OX environment.
I guess I’d have to
modify my “review it once and ignore them after that…” position. If you
review the status 1’s on a regular basis and check with the application owners
to ensure that the files are NOT critical to a restore of the application (like
some error log files or such) and place these files into the exclude list, then
you are covered. This will switch the system getting status 1’s to status
zero. That way IF things change (like someone adding a new application or
the application starts to behave differently, you will notice it because you
start seeing status 1’s.
Definitely agree with
having an exclude list for the database stuff if you are handling the database
backups separately as a special form of backup.
-stuart
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Jeff Lightner
Sent: Thursday, April 10, 2008 6:13
AM
To: Weber, Philip;
VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Top 20 (or so)
misunderstood things about NBU
I’ll have to disagree
with the idea of not using exclude lists. A couple of reasons to use
them:
1)
Separate OS and
application/database backups. You do not want to have a policy that
backs up from / on a system that has GBs or TBs of database on it when you have
a separate policy for the database backups. In multi-tier environments it
is even more important that you backup the DB from one server along with middle
tier or other levels from other servers as part of an “environment” backup
rather than a “server” backup.
2)
Not having excluded the
known items that can’t be backed up (e.g. /proc on Linux, door files on Solaris)
you have no idea whether the status 1 you just got was only for those known
items or for other items that WERE critical to you ability to
recover. In at least one Federally regulated industry I was expected
to explain every file that caused a status 1. If I did that in the
official backup documentation (required by those same regulations) I could put
it in the exclude lists and NOT have to explain it each day. For
those of us that know and love S-OX this might be a good pre-emptive measure for
overzealous S-OX audits.
----------------------------------
