NetBackup v6.0 Issues

[Tim_Rae]

Hi There,

I recently upgraded a customer to v6.0 MP2 from v5.1 MP4. I had a few niggling issues with nbpushdata but I got past these and everything went according to plan.

But now after the upgrade I'm finding some servers are not starting at all according to the the start window and schedule. When we do manual backup they work fine. It just seems to be the scheduling via the policy.

Anyone seen similar issues? I currently have a case opened with Symantec.

Cheers,
Tim.

[Chia_Tan_Beng]

Tim,

I heard about someone having some similar experience and deleting & re-creating the policy solved the problem.

If the policies involved are not a lot and customer is on your back, no harm try it on one ot two policies.

[Chuck_Stevens]

Hoo-boy, it isn't just me!

Yes, I had (yes, had) this problem, and it came from a variety of sources.

Three things to check:

1. Install MP2. Immediately.

2. If you are using a frequency-based schedule, and you want the backup to run once per day, make the frequency "1 day", not anything less. I had everything set to 9 hours (1 hour more than the 8-hour window), and had tons of trouble. Resetting them all to 1 day fixed it. Mostly.

3. Sometimes, for some reason, the file "pempersist" (which allegedly tracks active jobs) will get wonky, and NetBackup will think certain jobs are active when they really aren't. In this case, the Polciy Execution Manager (pem) won't schedule the job for another run. In this case, do this:

a) Make sure you have no jobs running
b) Stop all NetBackup services (or just run bpdown)
c) Find the file "pempersist" in the NetBackup\bin\bpsched.d\ directory, and rename it (pempersist.old, for example)
d) Restart NetBackup services (run bpup)

(Note: I still have an open case with Symantec on the pempersist issue; there may be more information forthcoming.)

Good luck!

[Chuck_Stevens]

> Tim,
>
> I heard about someone having some similar experience
> and deleting & re-creating the policy solved the
> problem.
>
> If the policies involved are not a lot and customer
> is on your back, no harm try it on one ot two
> policies.


Note: Deleting and re-creating the policies may work, or it may not (it didn't for me) but it is only a work-around. It is a lot of work; I wouldn't go this route unless you have tried everything else.

[AKopel]

Yep,
We had good luck recreating policies, but it was to fix some other (kind of related) issues. I don't believe it will fix all of your schedule issues. We are also still experiencing some intermittent problems with clients running as they are supposed to. Chuck, I will be curious to here what you find out from tech support. We also have a ticket in.
Here are the things that 'seem' to be happening for us:

1) When we run our full backups (which also are in-line tape copy jobs), if they fail for some reason (media write error etc) they may not run incremental's the next day (or ever again in some cases) This is not consistent, but happens enough to be concerned.

2) For our Full backups with multiple data streams, it is even weirder. If ONE of the streams fails (media write error), first of all, it won't requeue like the non-multiple stream jobs; it just goes to incomplete, and then fails and never tries again in the window. If I catch the job, before the incomplete falls over to a failure, and RESUME the job, it will finish successfully, but then, the incremental's the next day will not run ONLY for that stream.

I will update this if we get an answer also...
We are also on MP2.

Aaron

[Tim_Rae]

Thanks gents.

I've already tried re-creating the policies from scratch and that didn't help. Mind you, the customer re-created them, I think i will attend site and do it myself (just for peace of mind) They have 7 polices all up, so shouldn't take too long.

^^EDIT: sorry, bit of partner/reseller talk there :p

I was thinking of re-installing MP2 as well? maybe it didn't update the binaries first time round correctly.

Cheers,
Tim.Message was edited by:
Tim Rae

[Stumpr2]

> was thinking of re-installing MP2 as well? maybe it didn't update the binaries first time round correctly.

yes, this is a good idea. I do not trust the VERITAS install scripts to completely shutdown all of the binaries before the upgrade. I always do the
bp.kill_all/bpdown -f -v
followed by bpps
to to ensure that all of the services/daemons are down.