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
|
