Policies not starting 2

[hankmanz]

Environment: Multiple WIN2K servers as clients
Single backup server running NetBackup 4.5
(with all known patches applied)

Created a policy with five jobs contained in it.
Friday: Full backup written to a specified volume pool
Monday: Cumulative incremental written to same vol pool
Tuesday: Same
Thursday:Same
Friday: Same

Window: 7 PM until 7 AM the next day
Frequency: Every five weeks (there are five sets of tapes)
Retention: Five weeks

Problem: Friday job kicks off and runs to completion, backing up all 14 clients. Mon-Thu jobs never kick off. If started manually, they run fine. A look at the bpsched log hints that they think that the job ran n days ago (n being the number of days since the Friday full backup ran).

Apparently, the first job is confusing the scheduler even though five separate jobs have been created under the policy.

Any ideas, first on whether I am looking at a bug and second on how to do what I want to do?

 

[PGPhantom]

This is a common problem.
Your frequency and windows overlap. What I do ...

For the full backup on Friday - I have a window of 20 hours and a frequency set to once over 24 hours.

For the incrementals I have a window of 10 hours and a frequency set to once every 12 hours.

With this setup - I have never, ever missed a single job and I have an average of 550 jobs running a day.

 

[hankmanz]

I sort of follow your reasoning and I will puzzle it out completely at lunch, plus I have sent it on to our installation contractor, but there is something else going on here. I need a frequency of five weeks because I want to have five sets of tapes which means that I can separate my backups week by week without having to pop for the Vault option and without having to be at work every Friday for the rest of my life to eject tapes used during the previous week. So the frequency of five weeks is what kicks off the correct job for each week 1-5. I tried calendar-based backups, but Veritas has explained to me that it will not work if the window spans midnight. We are bound to the backup week starting on Friday and ending with the Thursday night backups because our validated SOP says so and it will be very hard to change. We are also bound to being able to separate tapes by week. So there are five policies, each writing to a different volume pool which means I should be able to walk away for five weeks before I have to start worrying. Any further thoughts on this problem?

 

[PGPhantom]

How about trying ...

Have one job (Full Backup)with a frequency of once per day and a window of Friday only say from 6:00 p.m. to Saturday at 2:00 p.m. too ensure that it runs.

Set your incrementals to a frequency of once every 12 hours and a window Sunday-Thursday 6:00 p.m. - 4:00 a.m. the following day - Change the Sunday to Saturday or include Saturday as well.

Next - You will have to try this to make sure that it works ... Use a scheduler program to set up a few jobs. Run the following command:
bpplschedrep <policy name> <schedule name> -pool <what pool you want to use>
You can set it to run on specific days such as a different job every Friday at 4:00 p.m. that will automatically change the pool for that specific schedule. It should work - Let me know.

 

[hankmanz]

That is a very interesting idea--I was not aware that the volume pool assigned to the policy could be changed from the command line. Your earlier tip about changing the frequency was another piece of the puzzle. It means that I can simply create a policy with just two jobs--full which runs once and cumulative incrementals which run Monday through Thursday with a frequency of just a shade more than the window value to keep anything from running twice when midnight is spanned. Then every week I kick off a job to change the volume pool assignment. How I will schedule those is still up in the air, but I think I can manage it.

The problem arises because NBU applies the frequency as a global attribute. If I run a job on Friday with a frequency of, say, five weeks, then I cannot run any other job under that policy for five weeks even though they are separate jobs. I believe that means that a frequency of more than 24 hours is useless--I am not sure why other choices were even included by Veritas.

Calendar scheduling has similar problems. The windows are treated sort of globally within the policy and the spanned-midnight problem causes jobs to run twice in the same window plus jobs from the next day also kick off because they see the open window as well. Veritas looked at that problem and called it a bug, then advised me to use frequency-based scheduling.

I must admit that I was very surprised that NBU does not support the idea of separate tape sets in the base product. I am also surprised that so much work has to be put in just to get jobs to run when the operator wants them to run. From my point of view, the whole window concept is overkill. I just want to schedule jobs, have them run once, and run to completion. If they are running during the day, I am sure I will hear about it, but missing a backup is far worse for me than an occasional user inconvenience.

I will start running tests on your idea this afternoon--Thanks!!

 

[PGPhantom]

Don't underestimate the reason for the choices - They fit a lot of diverse environments and many, many differing requirements.

The HUGE benefit to NetBackup DataCentre is that the GUI provides about 70% of the use and this makes it easy and less confusing to the novice user. For the additional 30%, everything in the GUI and more can be done from the command line - This is a great strength as everything can be scripted.

 

[hankmanz]

Yeah--but NBU cannot do SIMPLE scheduling and SIMPLE tape separation and that is a massive drawback, given the price. My original comment stands--there appears to be little use for a frequency of more than 24 hours and something like 5 weeks, which would appear to be an answer, is not. And I would have to say that the GUI interface is about 1998, not 2003, since so much in the way of administration is not implemented or does not work as expected. I would also have to say that no novice to backups should even try using this product unless they have a very good consultant guiding them.

By the way--it looks like your idea works. There are a couple of gotchas with, of course, frequency, and there is the added requirement that the history saves have to have a retenion of infinity rather than five weeks, but I have a working model that will get the acid test when I start a new week tomorrow. The same job that changes the volume pool assignment can also change the expiration date to infinity. Huge thanks for your suggestion. At the very least it will allow me to take a short vacation this summer.

The only thing that could kill this is when somebody decides that we need backups for weekends as well and then I will have a problem figuring out when the fulls end since I cannot &quot;stack&quot; backups.

 

[hankmanz]

The tip from PGPhantom was first rate. I now have a single policy for each type of backup I do (NT Servers, Exchange, SQL, etc.) Under each policy are just two schedules--one for full backups on Friday, one for incrementals Monday-Thursday. Window and frequency are set appropriately. Then, each week, a script involving bpplschedrep runs to modify the volume pool and sometimes the retention level. In the fifth week, the script is slightly different because the fulls get a special volume pool (History) and a retention level of infinity while the incrementals go to the Week 5 volume pool with a retention level of 5 weeks. Pulling tapes for offsite storage is very easy since they are now in a volume pool keyed to the week. In fact, that can also be automated. Scheduling of those scripts under Windows is almost trivial. I understand that Vault does far more than I am doing, but this is all I need to do so it has saved my company a minimum of $8,000. My thanks to Tek-Tips and PGPhantom.

 

[PGPhantom]

My pleasure - Glad that I could help.