Curtis,
I think there are horses for courses and I think I should share my opinion so that readers can hear both sides.
I have a few hundred windows servers in my windows server filesystem backup and the same for UNIX. There's also one for DBs (1 for UNIX and 1 for WIN) and another couple for the exchange 5.5 disasters. As you said I have some single ones for the few that have special requirements. But being a one man shop right now with so many clients to look after I feel I have no choice.
I use multiplexing to stream as many clients to a drive that I can and so far it has been streaming well. With single client policies you must be using some DSUs as I'm not sure how you would do it with tape drives. They would be tied up by single clients wouldn't they ? I only have a few DSUs so I have to multiplex a lot of my stuff to the tape drives.
Also, have you haven't mentioned the issues with Nbpem when you have so many policies. It takes ages to run through policies and start kicking off jobs ie about 1hr for 500+ policies and 1500 clients. With 6000 policies I would hate to see how long it takes, do you ever bounce netbackup on that system ?
Yes, you need to enforce standards and rules as to when you will allow backups to happen and they might be exceptions but there should only be a few. It is good for debugging but I only do that as a temp thing and then put them into the bulk policies. But really, I can't see how managing 30 policies vs 600 is a bad thing. I actually did some work for a site which was in the 600 policy situation and they wanted me to help them consolidate and yes they suggested it, not me.
> 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.
Yes, it brings up all the policies but in separate windows and you change them individually. This takes ages but with a single policy it's easy.
> 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?
Again, why run scripts with bulk changes when you can do single policy changes. More changes = more risks. I know you can say one change on a policy can affect a lot of clients but it's easier to change back. I have seen policy corruption in netbackup and normally you need to delete it and recreate it by hand. Copying a corrupted policy will spread corruption.
> 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.
I'd rather add a client to a policy than add an extra policy ie stop issues like the nbpem scheduler delay after start up.
Anyway, in summary I don't totally disagree with Curtis, you do need a few policies but not one or multiple for each client. Also, I'm not saying that there should be one policy to rule them all !!! So far I've seen an average of %10 of the number of clients = number of policies and this seems to work well. But in a simple and/or small environment this may be less and in a large and/or complex one it may be more.
As a rule of thumb I setup 1 windows and 1 unix filesystem policy and a 1 unix and 1 windows DB policy. Then add more for mail servers, DMZ setups, SQL, DW, NDMP, VMS etc etc if need be. Then hopefully you can multiplex well, max the tape drives, use some DSUs if you have any and have a fairly manageable setup.
In the end it come's down to what works for you, what you're happy with and provides you with a good reliable system to restore data. I don't want to tell people what to do, just want to share my experience.
My 2 cents worth.
Dom
Still a supporter of Curtis 99% of the time.
-----Original Message-----
From: Curtis Preston [mailto:cpreston AT glasshouse DOT com]
Sent: Friday, 18 January 2008 5:07 AM
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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
| 