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.
----------------------------------