All
Well I see the objective in one client per policy if it is unique (ie:
Windows Cluster, SQL, Exchange, Certain Drive letters to be backed up
for unique systems, Virtual Machines, ect), but I have one policy that
contains 30 clients and has never caused any extra work, or overhead for
me or the system itself.

But I think this is an each to their own scenario. What works in one
way, may not suit someone else.

Simon

-----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 Curtis
Preston
Sent: Thursday, January 17, 2008 7:13 PM
To: Ed Wilts
Cc: Randy Samora; VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] One Client Per Policy


What I'm advocating is a single client per policy, not a single policy
per client, so we're in complete agreement.  What I _don't_ like is the
usual practice of putting a bunch of clients in one policy.  It
minimizes the number of policies, but so what?  I think it maximizes
work, as I describe in my previous post.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

-----Original Message-----
From: Ed Wilts [mailto:ewilts AT ewilts DOT org] 
Sent: Thursday, January 17, 2008 10:44 AM
To: Curtis Preston
Cc: Randy Samora; VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] One Client Per Policy

There are also cases where more than 1 policy per client makes sense.
I've got 1 client where I have one policy per filesystem, and I'll
explain why.

NetBackup takes snapshots at the beginning of the *parent* job, not at
the beginning of each child job.  If you do a lot of FlashBackups,
you'll find that taking the snapshot right away but not starting the
backup until hours (or potentially days) later is really a dumb idea.
You tend to have a lot of snapshots lying around wasting disk and cpu
resources for absolutely no good reason.  You'll have to allocate
snapshot disk space that you don't even care about since your backup
hasn't started yet and that backup could subsequently fail with a 196 if
you have too many backups queued up (yes, this is acceptable on this
client).

I logged a call with Symantec and they said that they would not change
this behavior.  So....1 policy per filesystem (for a subset of the
filesystems no less!) with coordinated access through a DSSU to control
how many can actually run.

I have other cases where different file systems may have different
scheduling requirements and that also forces you to split things up
between policies.

In general, we do not have a single policy per client though. Databases
and wannabe clusters without cluster-wide filesystems are the common
exception to this rule.

-- 
Ed Wilts, Mounds View, MN, USA
mailto:ewilts AT ewilts DOT org

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

This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and all
liability if this email transmission was virus corrupted, altered or
falsified.
---------------------------------------------------------------------
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

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