Thanks to everyone who has responded so far. If you want to weigh in on the topic, I'll keep the poll open for four more days.
thanks, tim On Jan 23, 2008 11:08 PM, tim burlowski <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Martin, > > Jonathan > > Sent: Wednesday, January 23, 2008 8:17 AM > > > > To: VERITAS-BU@mailman.eng.auburn.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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Holowinski, > > Scott > > Sent: Wednesday, January 23, 2008 10:39 AM > > To: Randy Samora > > Cc: VERITAS-BU@mailman.eng.auburn.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:[EMAIL PROTECTED] > > Sent: Thursday, January 17, 2008 7:43 AM > > To: VERITAS-BU@mailman.eng.auburn.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 > > > > [EMAIL PROTECTED] > > > > 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@mailman.eng.auburn.edu > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > > > > > > -- > tim burlowski > http://timbu.org/mtblog > -- tim burlowski http://timbu.org/mtblog _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
