I vote this for thread of the month.

Since there was so much talk on this topic I made a quick survey if
people care to vote their preference.

http://www.surveymonkey.com/s.aspx?sm=N_2fMf4zEKDnHEU8Un_2bLf8fg_3d_3d

I'll publish the results in a week. In the interest of full disclosure
I work for Symantec.

tim

On Jan 23, 2008 1:39 PM, Curtis Preston <cpreston AT glasshouse DOT com> wrote:
>
>
>
>
> As long as you realize that I'm just respectfully discussing and not trying
> to be argumentative, I'll continue to respond.  I do think you should do
> what makes sense to you.  If my approach doesn't make sense to you, then by
> all means don't use it.
>
>
>
> I completely agree with KISS, but I think my approach is the simplest and
> easiest to understand.  It's just not how it's typically done.  Questions
> like which clients are production, or oracle, or whatever, are answered by a
> proper policy naming convention (e.g. all production policies start with P_
> or Prod_).
>
>
>
> The two big advantages that I will remind you of is how things work when
> need to stop backups on a given client (much easier), and how they work when
> you need to re-run a failed backup (very easy).
>
>
>
> I'll admit that unless you are scripting the creation of your policies
> (which I do from a script that reads a spreadsheet actually), then putting
> one client per policy is a lot of initial work in medium to large
> environments.  But I think it's then easier to maintain after that.
>
>
>
> This discussion is fun!
>
>
>
>
>
> ---
>
> W. Curtis Preston
>
> Backup Blog @ www.backupcentral.com
>
> VP Data Protection, GlassHouse Technologies
>
>  ________________________________
>
>
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Martin,
> Jonathan
>  Sent: Wednesday, January 23, 2008 8:17 AM
>
>  To: VERITAS-BU AT mailman.eng.auburn DOT edu
>
>  Subject: Re: [Veritas-bu] One Client Per Policy
>
>
>
>
>
> I think the back and forth on this issue has been quite interesting and I'll
> reserve judgment on the one client per policy option until I've personally
> tried it, but generally speaking my I.T. policy is KISS - KEEP IT SIMPLE
> STUPID.  This means (to me) if there is no inherent value in doing something
> then don't do it.  I tried to limit the number of policies I've created and
> only created new policies when needed.  I think Curtis at one point said its
> best to lump all your Netbackup resources together and let Netbackup sort it
> out.  I think at the time he was referring to storage units, but I think
> similarly along policy lines.  I only create new policies when required, and
> the only requirements in my environment are are as follows:
>
>
>
> 1) Production versus Development - This is a policy requirement required for
> Disaster Recovery
>
> 2) Type of Netbackup job - Windows / Std / Oracle etc...
>
> 3) Scheduling Conflicts - Some servers just have to be backed up at special
> times
>
> 4) Storage Group Requirements - Some backups just have to go to special
> places
>
>
>
> I've got some 50 active policies for 197 clients at my largest site.  That
> said, 99 of those machines are in 2 policies - Production Windows and
> Production Standard.  I break clients out into their own policies when
> required so I can have granular control, but I'm not quite convinced on the
> value of breaking EVERY machine down into it's own policy / I don't know
> that I want that many variables to fret over.  When I do reporting, I report
> by Policy.  Its much easier for me to identify - all Production Oracle
> Servers backed up 13TB this week in 48 hours because they are all in the
> production - oracle policy (as an example) based on policy than to find the
> list of Production oracle servers, and list them individually.
>
>
>
> Anyhow, I see my current solution as a hybrid.  I've got many policies with
> only one client in them but I maintain simplicity by grouping servers with
> non-specific requirements.  I'll give the one client per policy thing a go
> sometime and let you know if I feel differently afterwards.
>
>
>
> -Jonathan
>
>
>  ________________________________
>
>
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of 
> Holowinski,
> Scott
>  Sent: Wednesday, January 23, 2008 10:39 AM
>  To: Randy Samora
>  Cc: VERITAS-BU AT mailman.eng.auburn DOT edu
>  Subject: Re: [Veritas-bu] One Client Per Policy
>
> That is my current setup.  575 policies and about 500 clients.  Some overlap
> for DB and OS backups.  I have also worked in an environment were I put 30+
> clients in a policy.
>
>
>
> I would say that for the initial setup the one client per policy is a pain.
> But I find that reporting and management in general is easier with one
> client in a policy.
>
>
>
>
>
>
> Scott
>
>  ________________________________
>
>
> From: Randy Samora [mailto:Randy.Samora AT stewart DOT com]
>  Sent: Thursday, January 17, 2008 7:43 AM
>  To: VERITAS-BU AT mailman.eng.auburn DOT edu
>  Subject: [Veritas-bu] One Client Per Policy
>
>
>
> NetBackup 6.0 MP5; Windows 2003 Server and clients.
>
>
>
> I heard this suggested again in conversation and wanted to find out if
> anyone else is creating a separate policy for each client?  I was up to
> almost 800 clients, slowing getting down to about 600 clients, but will grow
> again in 2008.
>
>
>
> The original setup would take quite a while but I can see some pros and some
> cons.  Is anyone actually running that way with hundreds of clients?
>
>
>
>
>
> Thank you,
>
> Randy Samora
>
> Team Lead - Enterprise Backup & Recovery
>
> Enterprise Server and Storage Systems
>
> randy.samora AT stewart DOT com
>
> Mobile: 713.256.8224
>
> Office:  713.625-8369
>
>
>
>
>
>
>
>
>
> Privileged/Confidential Information may be contained in this message or
> attachments hereto. Please advise immediately if you or your employer do not
> consent to Internet email for messages of this kind. Opinions, conclusions
> and other information in this message that do not relate to the official
> business of this company shall be understood as neither given nor endorsed
> by it.
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>



-- 
tim burlowski
http://timbu.org/mtblog
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu