100% agreed Stu
S.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart
Liddle
Sent: Monday, April 14, 2008 11:13 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Status 1's and exclude lists (was Top 20 (or
so)misunderstood things about NBU)
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Lightner
Sent: Thursday, April 10, 2008 6:13 AM
To: Weber, Philip; VERITAS-BU@mailman.eng.auburn.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.
--
This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and all
liability if this email transmission was virus corrupted, altered or
falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England___
Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
