I agree with verifying with the application support techs on what
files are being skipped and how to address them as they are responsible
for their applications but as the backup and operating system
administrator I am held accountable for recovery. I don't like exclude
lists especially if it is just to make the reports look good for status
0. I have found that in too many cases an exclude list in created and
then another administrator or application support tech will make a
change and now important files are being skipped that shouldn't be. If
coordinated correctly with procedures and documentation this should not
be the case but there is still the reliance upon human intervention to
follow procedures and to document.

 

Regards

 

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart
Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

Yes....very true.  What I recommend doing is to check all backups
against a new client the first few times and see what is causing the
partial success.  Checking with the application support people on what
files are OK to skip is always a good idea and will definitely eliminate
problems in the future.  Then use this information to build an exclude
list for the client.

 

I used to treat databases as a special case for backups since they are
so temperamental.  I would do SQL databases by having the SQL DBA's do
their own backup of the db to the local filesystem (or a network share).
Then we would have the DBA's put together an exclude list for their SQL
servers to exclude the active DB files.  Then we would schedule our
backup jobs for a time AFTER the SQL local  backups.  Never had to worry
about restoring SQL DB's after that.   But, testing database restores is
very critical to ensuring that you are backing up the right thing(s).
And you definitely need the assistance of the DBA's for this.

 

-stuart

 

________________________________

From: Jeff Lightner [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

I'd amend point 3 to say "does NOT ALWAYS mean".  

 

There are many OS and filesystem level backups that are complete despite
status 1.   However, having a status 1 on a database backup can be a
real killer...

 

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart
Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

I think I would agree with all of what Ed has stated here.  However, I
think that these points would apply to ANY backup product and not just
NBU.

 

Since the question was about the "top 20 (or so) misunderstood things
about NBU", I'd have to add the following:

 

1)     Yes, there is a command line interface!  The GUI is NOT the only
way to do things with NBU.  (yeah, this might be generic,  but...)

2)     Multiplexing and Multistreaming are not the same thing and both
need to be tuned properly in order to optimize your backups.

3)     A return code of "1" on a backup does NOT mean that the backup
has failed.  Nor does it mean that the files that could not be backed up
are essential to the recovery of the system.  (This DOES mean that the
backup admin needs to have a discussion with the system admins and
application support folks about what files can be safely ignored on
backups.  Building exclude lists helps.)  
I had to explain to a manager once why we treated a return code "1"
(partial success) the same as return code zero (successful).  His
thought was that he wanted everything to be zero return code!

4)     Yes, NBU includes reporting, but it is no substitute for a 3rd
party reporting tool like Bocada.  (another item that could be about any
backup tool).

 

 

I'll have to think up some other NBU specific items and add to this list
later.

 

-stuart

 

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

On Mon, Mar 31, 2008 at 4:48 PM, Curtis Preston
<[EMAIL PROTECTED]> wrote:

        What are the top 5/20/30 things about NBU that you think people
get wrong?


1.  People think that you're working on a backup system.   You're not -
you're working on a *recovery* system.  If you can't recover, backups
are useless.

2.  File system backups are not a replacement for bare metal restore.
It is usually not acceptable to just do a fresh install, restore files,
and expect to be back to where they're started

3.  Error messages really are important.  Check them every day or you'll
eventually discover that failures were missed in the noise and backups
haven't run in a long time.  When you do a restore is not the time to
check to see if backups actually ran.

4.  Audits are important.  The larger the environment, the more likely
it is that file systems are missed.  This is especially true of
clusters.  Sometimes it's not the failures that get you but the lack of
attempts.

5.  Backing up clusters by physical host names will cause you grief.

6.  Application owners are responsible for ensuring the application is
recoverable.  A backup admin, working in a vacuum, can not help you. 


7.  Test your restores regularly.

There are lots more but this is a start...

-- 
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED] 

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
confidential information and is for the sole use of the intended
recipient(s). If you are not the intended recipient, any disclosure,
copying, distribution, or use of the contents of this information is
prohibited and may be unlawful. If you have received this electronic
transmission in error, please reply immediately to the sender that you
have received the message in error, and delete it. Thank you.
----------------------------------

_______________________________________________
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Reply via email to