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!

 

 

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.

 

 

 

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.