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
|