Veritas-bu

Re: [Veritas-bu] "/" + Cross All Mnt Pts Vs. ALL_LOCAL_DRIVES

2008-10-24 11:11:21
Subject: Re: [Veritas-bu] "/" + Cross All Mnt Pts Vs. ALL_LOCAL_DRIVES
From: Len Boyle <Len.Boyle AT sas DOT com>
To: Dean <dean.deano AT gmail DOT com>, Curtis Preston <cpreston AT glasshouse DOT com>
Date: Fri, 24 Oct 2008 10:53:55 -0400
For the two slow off the disk clients, you could leave them with the multiple 
streams turned on. Then set the client option maxjobs to 1. Use can use the 
bpclient command or the gui. 
This way if the backup job fails for these clients, netbackup only has to retry 
the failed streams and not the whole backup job. 

Len 

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Dean
Sent: Friday, October 24, 2008 10:01 AM
To: Curtis Preston
Cc: Veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] "/" + Cross All Mnt Pts Vs. ALL_LOCAL_DRIVES

Agreed. Generally you don't want to be specifying what you DO want to
backup. I think you should, by default, backup everything, then
specify the exceptions that you DON'T want to backup.

I've been doing storage and backup management for longer than I care
to mention, and the number one rule is, it's better to be safe than
sorry.

But I do see Matt's point. Of the 400-odd clients we backup, there are
2 where the read-from-disk performance is so bad that I can only run
one stream at a time. These 2 clients get their own policy with
ALL_LOCAL_DRIVES, but with "allow multiple streams" turned off.

There are always going to be exceptions, but I believe the default
policy should be ALL_LOCAL_DRIVES with multiple streams.

- Dean

On Sat, Oct 25, 2008 at 12:06 AM, Curtis Preston
<cpreston AT glasshouse DOT com> wrote:
> You are correct that this will create multiple jobs that run at the same time 
> (if you allow multiple jobs to run at the same time).  My experience has been 
> that the backups of the "lesser" filesystems finish in a couple of minutes 
> and any thrashing is minimal at most and very short lived.
>
> IMO, the value provided by the method you're espousing is significantly 
> outweighed by the risk created by manually maintaining include lists.  I'm 
> much more concerned that something will get missed than I am that I'm going 
> to give the OS drive a little exercise for a few minutes per day.
>
>
> Curtis Preston  |  VP Data Protection
> GlassHouse Technologies, Inc.
>
> T: +1 760 710 2004 |  C: +1 760 419 5838 |  F: +1 760 710 2009
> cpreston AT glasshouse DOT com |  www.glasshouse.com
> Infrastructure :: Optimized
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of 
> Clausen, Matt R [EQ]
> Sent: Wednesday, October 22, 2008 6:18 AM
> To: 'Dean'; Nathan Kippen; Veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] "/" + Cross All Mnt Pts Vs. ALL_LOCAL_DRIVES
>
> I have to disagree with the ALL_LOCAL_DRIVES being a good thing in some 
> circumstances. I recently went from using ALL_LOCAL_DRIVES to specifying each 
> of my disk slices (/, /usr, /var, /opt, etc.) and breaking them out with 
> NEW_STREAM on my UNIX servers for a very simple reason. Using 
> ALL_LOCAL_DRIVES and multiple streams will thrash the disks on that type of 
> machine.
>
> Think of it like this.... You have several disk slices or partitions, but 
> they all share a single "disk". When you do ALL_LOCAL_DRIVES + Multiple 
> Streams then you are in fact initiating a stream per partition/slice. This 
> can be upwards of 4-5 streams hitting a single disk which means the head is 
> jumping around all over the place to provide the data flow and wearing your 
> disk out.
>
> I've been to a few of the NetBackup classes, and in every one I've been told 
> to never let the number of streams exceed the number of spindles in the 
> physical hardware you're backing up. With specifying my directories 
> individually I can regulate the streams so that I am not overtaxing my disk 
> hardware. If I have say / + /usr + /var on one disk mirror, then I can 
> specify those directories then the NEW_STREAM and then my /opt directory 
> which is a ZFS pool on another set of disks. This way I am not running the 
> risk of thrashing the disks and reducing their service life prematurely.
>
> Your mileage my vary of course; there are arguments for both sets of 
> thinking. I just found what the instructors were saying to be a very 
> compelling argument to avoid ALL_LOCAL_DRIVES for my UNIX servers and keep 
> using it mainly for my Windows servers where each drive is generally a 
> physical drive.
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Dean
> Sent: Wednesday, October 22, 2008 3:01 AM
> To: Nathan Kippen; Veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] "/" + Cross All Mnt Pts Vs. ALL_LOCAL_DRIVES
>
> We use ALL_LOCAL_DRIVES and "allow multiple streams" everywhere,
> regardless of the O/S.
>
> Where there is a database that needs to be backed up seperately, it
> will have it's own policy just for that database, on that client, and
> the backup selection list might look like :
>
> /opt/oracle
> /oradata/db1
> /oradata/db2
> /oradata/db3
>
> Then, we back up the rest of the client in a more generic "catch all"
> policy ... say a policy named "unix_system_prod", which contains many
> clients and has ALL_LOCAL_DRIVES in it's selection list.
>
> We setup an exclude list for that particular client, for only the
> "unix_system_prod" policy, which contains the entries listed above, so
> that we're not backing up the db files twice.
>
> ALL_LOCAL_DRIVES is a good thing! It means never having to say "Umm...
> sorry... we don't have a backup. The Unix guy didn't tell us when he
> added that /super_critical mountpoint 3 years ago."
>
>
> On Wed, Oct 22, 2008 at 8:24 AM, Nathan Kippen <nate.kippen AT gmail DOT com> 
> wrote:
>> I'm just looking to see what the recommendation out there is for backing up
>> unix-based servers.
>>
>> In the past I've always backed up a unix client using "/" in my selection
>> list and using cross all mount points + exclude lists.  As I was browsing
>> through the Admin guide I read that ALL_LOCAL_DRIVES could be used on
>> unix-based clients as well.
>>
>> I'm interested to know how people out there backup their unix clients.   We
>> use cross all mount points so to make sure that an Admin doesn't create
>> something on a client that needs to be backed up that he doesn't tell us
>> [backup admins] about.
>>
>> I'm looking into using the ALL_LOCAL_DRIVES directive with "allow multiple
>> streams" so I can stream out my unix clients by filesystem thus getting more
>> i/o throughput by having the backups read from multiple physical disks at
>> the same time.  ... This opposed to using "/" + NEW_STREAM .. since I don't
>> really know what directories are actual filesystems.  (I don't admin the
>> majority of the clients I backup.)
>>
>> Thanks,
>>
>>
>>
>>
>> _______________________________________________
>> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
>>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>
>
>
> This email and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. If 
> you have received this email in error please notify the system manager. This 
> message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail.
>
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


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