I would dump the automatic schedules and just use the Application schedules in separate policies with different retentions.  Remember the Application schedules will be run from the SQL server and can be scheduled by the SQL DBA's with their own scheduler.  They would specify the policy and thus the retention.

I agree - put them in different policies.

Hi,

I also agree. You need each application and Automatic schedule in different polices for each of your retention periods.

So your yearly auto and application backups are in one policy etc

That's well and good, but won't Netbackup create duplicate backups then? My understanding is that Netbackup manages the frequencies in a given Policy, as opposed to the Client?

So if today, I create 4 separate policies, one for each Frequency described above, won't all four run this weekend when they are scheduled? Leaving me with a Weekly, Monthly, Quarterly and Yearly back up. And after that, whenever more than one happen to be scheduled, they will run again.

As I mentioned in my first reply, if you only use the Application schedule that is automatically created when you set up the policy (type MS-SQL-Server), then the SQL DBA's will control when the policy is run and NOT NetBackup master server scheduling.

This is a departure from what most NetBackup admins are used to, but trust me, it works.  This way it's a user-directed backup and the scheduling is outside of NetBackup control

The SQL admins will run the backup of the appropriate policy and then you will get the retentions that you want based upon the policy that they run.

require that someone run those manually from the SQL side, or is it automated? I'm not familiar with it, but if it's going to require the SQL Admin to do and manage manually, that's not really any better.

I'm not a SQL DBA, but I have worked with them on this issue.  There is a scheduler that is part of SQL server plus they have the option of using the NetBackup GUI on the client to run their SQL backups.  In addition they can run them from the command line.

In each case, the SQL DBA would provide the name of the NetBackup policy and also the name of a saved SQL batch (.bch) files which are used as the filelist in the NBU policy.

So, yes, it's automated (and controlled by the SQL DBA on the SQL server)....but the benefit is that it's the DBA's responsibility and not yours.  From the standpoint of getting the DBA's involved that is a huge plus.  Most DBA's that I've worked with would like that ability.

but it still sounds like it will require hands on management to get the desired result, which defeats the purpose in my opinion. Only means that it's in someone else is doing it.

So, am I correct in my understanding that the only other options are as follows?

• 1. create separate policies using the "Frequency" scheduling, but this means that on certain weeks I will have 2 or more backups of the same thing (as the monthly, quarterly, yearly schedules begin to overlap with the weekly), which could also create a bottle neck with other backups running
• 2. create separate policies using "Calendar" scheduling and avoid having occasional multiple copies. But this is not a very user friendly process for these circumstances (in my opinion)
• 3. change each of my schedules in the ONE policy so that they don't overlap (this isn't really an option for us since it runs for most of the weekend, so we don't have enough time to do multiple ones. not to mention  that I don't see how this would prevent creating multiple back ups in the same week)

If the above is correct, I think I'll go ahead create separate policies and go to the trouble of planning out the "Calendar" scheduling accordingly, so as to avoid running multiples on any given weekend.

If you absolutely still want to have NetBackup control the SQL backups, then, yes, use separate policies and use calendar scheduling for the automatic schedules.

I was just stating my preference for giving control of the SQL backups over to the SQL admins since they have a vested interest in getting good backups.

I copied the original Policy that had multiple schedules, then edited each new policy so that it included only one of the desired schedules/retentions. Then I deactivated the original Policy.

The problem is that it appears that for some reason, the new Policies seem to be dependent on the original policy (from which all the new policies were copied), as it must be "Activated" or I get a Status Code 247. Plus it seems to be using the schedule in the original Policy as well, b/c I get a Status Code 199 if not with in the schedule on the original Policy.

What am I missing or doing wrong? Is some rule that you can't "Copy" SQL policies?