Veritas-bu

Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

2008-04-09 17:35:26
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU
From: "Haskins, Steve" <Steve.Haskins AT bannerhealth DOT com>
To: "Stuart Liddle" <stuart.liddle AT glasshouse DOT com>, "Jeff Lightner" <jlightner AT water DOT com>, <VERITAS-BU AT mailman.eng.auburn DOT edu>
Date: Wed, 9 Apr 2008 14:16:41 -0700

  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: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU AT mailman.eng.auburn DOT 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:jlightner AT water DOT com]
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU AT mailman.eng.auburn DOT 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: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Stuart Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU AT mailman.eng.auburn DOT 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: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Ed Wilts
Sent: Tuesday, April 01, 2008 8:11 AM
To: Curtis Preston
Cc: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

On Mon, Mar 31, 2008 at 4:48 PM, Curtis Preston <cpreston AT glasshouse DOT com> 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:ewilts AT ewilts DOT org

----------------------------------
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 AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
<Prev in Thread] Current Thread [Next in Thread>