Written by W. Curtis Preston
Monday, 02 April 2007 00:00
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's 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 Convential 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:
- 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.
- 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.
- 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.
- 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:
- 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?
- 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.
- 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.
I can't wait to see the comments on this one. :)
Add comment
Comments
Also our Operations group does not have access to the NB Java Gui so they cannot restart jobs from that method, they have to use Control-M.
Group policies doesn't allow them to function in the role we need them to function in.
My users tend to always say that their application absolutely has to be 24x7. So I counter with "then it doesn't matter when the backups run" and run full backups every night of the week, spreading out the load on my clients, servers, and tape devices. There are a few exceptions (and we do typically do most backups in the evenings) but in general, anybody can go any time.
I have not yet had a client tell me that they're only 5x12 and that's why backups have to run on weekends.
I would change the order of things so that it groups differently in a listing. (I would put sql first.) I would also add prod, dev, test.
I used to put the day of the full backup in the name, but changed my mind because it makes things difficult to move around, especially if you're using NBU. (If you change the full day then you have to change the policy name, and in NBU, that forces a full backup.)
I like phrases like this:
Prod_FS_elvis_ALL: production filesystem backup of ALL_LOCAL DRIVES
Prod_FS_PCI_apollo_ALL: production filesystem backup of all of apollo's drives and it's encrypted.
Dev_RMAN_elvis_ABCD: development backup of oracle using rman, backing up the ABCD instance on elvis
Test_FS_elvis_home1: test backup of the /home1 filesystem on elvis
What do your naming conventions look like?
I think if you are using staggered full policy, the day of the week the full runs should be included in the policy name, along with the backup type (sql, fs, etc).
Also if the server is sercure / PCI, that should go into the name too right?
Production / PCI db server full weekly:
pci_servername_domain_sql_week ly_mon
Doesn't seem to look right to me.
Ideas?
Script? What script is this? Where can I get it? There are many functionality improvements that Netbackup could use, but thats another thread.
Without the script, I think the best alternative is to have one policy per client backup function.
At least if you have one policy per client backup function, you could easily set up a specific backup selection list for that client and manage that through the Administrative GUI.
I'm not sure if having one or many policies changes this, though. The same bad thing you're describing could happen in the "many policy" world.
So in short, one client per policy makes it easier to specify specific backup selections per client.
Did I forget to mention that reason? I can't believe it! It's one of my favorites!
The 1.5 hour delay was a few versions ago. There's been a lot of work with the scheduler since then.
RSS feed for comments to this post