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. 🙂
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.