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 <tim.burlowski AT gmail DOT com> 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 <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
>
--
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
|
