I boarded the NetBackup train back in version 3.4 and I have been in reactive
mode ever since. After years of trial and error, my installation is fairly
stable and now I'm able to spend some time making things run better instead of
being happy they're running at all. Breaking up the policies was one option
and as long as Scheduler isn't taxed more having to handle the extra policies,
then this might be a viable solution. One of my biggest thorns as always been,
as you mentioned, moving a client from one policy to another. All of a sudden
the Quarterly backups want to run even though it's only Monday.
There's a lot to digest here and it all looks great on the surface. Not to
blow smoke up anyone's chimney but if Curtis Preston recommends it, how can you
go wrong :)
If I do implement this change, I will report back with my findings.
Thanks,
Randy
-----Original Message-----
From: Curtis Preston [mailto:cpreston AT glasshouse DOT com]
Sent: Thursday, January 17, 2008 12:07 PM
To: Randy Samora; VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] One Client Per Policy
I am a strong proponent of one client per policy. Here is a blog entry that I
made to that effect. I'll include the entire text of my entry here, but it's a
lot easier to read if you follow the URL below. You can also see what others
have said about it in their comments to the entry:
http://www.backupcentral.com/content/view/51/47/
There was also a discussion on the NetBackup mailing list that you can read
here:
http://tinyurl.com/26ufs2
If you're a NetBackup user, I know you think I'm crazy, but this is what I
like: One policy per client and per database instance, and I'm going to do my
best to convince you that it's a good idea.
What am I, nuts? That could be thousands of policies! That's right. And I am
suggesting that thousands of policies is now (as of 4.5) no more difficult to
manage than a few dozen policies. AND I suggest that it presents to you a much
more digestable, manageable set of things to manage. And no one that I've
talked into this "crazy" idea has ever regretted. Once they grok it, they love
it.
(Update: There was a discussion on the NetBackup mailing list about this, and
the support for it was a lot stronger than I thought. One person as over 4000
policies and loves it.) Check this out:
It's all about minimizing complexity and management, right? The Conventional
Wisdom says the best way to do that is to make one policy for Unix, one for
Windows, one for Oracle, etc. With Unix, Windows, MacOS, NDMP, Oracle,
Informix, SQL Server, Exchange, and Sybase, we've got nine policies -- sounds
manageable enough. If that's the way it stayed, I'd be all for that -- but it
never stays that way. Next thing you know, one or more (or all) of the
following happens:
1. The above assumes every client in each policy can do their full backups in
one night. Next thing you know, that doesn't work. (Many of you kick the full
backups off on Friday night and let them run all weekend. Next thing you know,
it doesn't fit into a weekend.) Now we have to start spreading it out across
the week or month. Spreading them across the week turns 9 policies into 56
policies really quick. If you spread them out across the month, you've got 252
policies. All you need to do is create all the policies you need, and move some
clients into each policy. Of course, that means a full backup on each client
that you move, since NBU doesn't share level data between policies.
2. Next thing you know, one of your policies is too full and it's backups won't
fit on the night you assigned them to. All you need to do is move some of the
clients to another policy. Ooops. Another full backup.
3. Along the way, you end up changing naming conventions, and you have backups
with all of the following policies in your backup history: Unix, Unix_Thursday,
Unix_First_Thursday, etc.
4. Now it's time to pass the torch on to the new backup person. How do they
wrap their heads around this mess? GlassHouse (the company I work for) does
hundreds of backup assessments (among other services), and we've seen this over
and over.
Let's compare this to my way. Put every client in its own policy, with a
naming convention that tells you what is. Something like
Prod-FS-Unix-clientname-ALL (the fs means filesystem backups). If it's an RMAN
policy, it would be Prod-RMAN-Win-clientname-instancename (where instancename
is the name of the instance that policy backs up). If you need to change their
schedules, change their schedules -- no full backup required.
Here are the objections, and why I don't think they hold water:
1. It's easier to make global changes when you have fewer changes.If you want
to change a bunch of clients in one policy, you make one change to one policy.
That's got to be harder when you have a bunch of policies.
> If you're a GUI person, all you need to do is shift-select all the policies
> you want to change in the GUI, make the modification you want to make, then
> save. NetBackup will update all of the policies.
> If you're a command line person, how hard is it to take a command that
> modifies one policy, and add a for loop around it to have it modify several
> policies?
2. When you need to add a new client, adding them to a new policy is harder
than just adding them to an existing policy that's already set up.
> If you're a GUI person, right click on a policy of the same type, and select
> "Copy to new policy." It'll make another policy that's the same as the first
> one. Then add the client to that policy. One extra step. Big deal.
> If you're a command line person, the bppolicynew command has a -sameas option
> to do the same thing.
3. NetBackup will choke with that many policies!
> Prior to 6.0, if you have 6000 policies (I've had this many) and you have it
> start all the backups at the same time (what I do, too, but that's a
> discussion for another blog entry), then it will take a while to get all the
> backups started. I've had it take up to an hour and a half, and the amount
> of time it took was predictable. All I did was move the window up an hour
> and a half, and all was well.
> 6.0's new scheduler doesn't have this problem.
This layout is very easy to understand. There's no question as to what clients
are in what policies. When you're trying to do a bpimagelist to find a certain
backup, that comes in handy. When you change schedules for load balancing
purposes you don't force a full backup. You can help understand what's
scheduled when by having a naming convention for schedules and looking at the
"summary of all policies" windows.
---
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 Randy
Samora
Sent: Thursday, January 17, 2008 6: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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
