Backup failure on Netbackup clients

[Blazer_2]

Dear all,

I performed scheduled backup in my netbackup base on my policy settings but sometimes few clients can't be triggered its job as scheduled. No error log entries could be found on these clients. What is the major problem for that ?

Netbackup version : 6.5.2

Blazer

[AntonioVargas]

hi,

the job fails because of the backup window? what's the error you get? try for example starting to check the maximum job per policy and per client values.

regards

[Andy_Welburn]

You haven't provided much info but check out this earlier post - it may be relevant

It deals with manually running jobs whose frequency then precludes the job running again the next time the window opens. No errors are reported for this as nothing has 'faulted' (more of a config issue).

[Blazer_2]

Dear Vargas,

The problem that I deal with is some netbackup clients did not start its scheduled job as normal and it seems to be "disappeared" when I checked their backup status on next day. No "error" log entries generated from those "disappeared" clients. In normal situation, every client should  "appeared" on activity monitor once they trigger its job within the backup time window but those clients failed to do so. Hope this clarify the situation that i have.

Regards,

Blazer

[AntonioVargas]

Hi,

start by making sure (i dont know if you already know that) if the backup was made or not.. go to restore and see if you have files for restore made in that day. Probably backup wasnt made so start looking after that to the policy for understand why that appened...

[marekkedzierski]

Blazer.. are you using 6.5.2 or 6.5.2A ?

6.5.2 has a problem with nbpem..

marekk

[zippy]

no error?

is the sched activated for these clients?

[Ron_Cohn]

Are you doing Calendar or Frequency based backups?

[Blazer_2]

Dear all,

My backup is implemented on Calendar base, Netbackup version is 6.5.2. Activity monitor did not show up the problem clients within the backup time window. Symantec suggested to recreate the policy for those clients but not guarantee fixing it. Anyone who had this situation before ?

Blazer

[marekkedzierski]

Install 6.5.2A.

6.5.2 has issues with schedluer. It's confirmed.

[J_H_Is_gone]

Blazer, I had the same issue.

after my upgrade to 6.5.2 Most of my jobs would kick off, but I would have a couple of servers in a policy that would not.  the policy had about 50 servers and 3 of the would never start.  Meaning I never saw a parent job for those clients.  Is this what you are seeing?   ( I had 2 different policies doing this).

On one policy I just deactivated the policy and reactivated it and that night it ran fine.

That did not work on the other one.

for the second policy I copied the policy to a new name ( did this on Friday as it was going to cause a full on all the clients)  and just gave it a 1 on the end of the policy.

this worked for this one.

Seems the database just needed to be reminded as to what servers were in the policy.  I did not call support on this as I got it working.  So I don't know if this the 'correct' way to fix it or not.  But I had the same problem and got it working for me.

[CRZ]

---

@Marek Kedzierski wrote:

Install 6.5.2A.

6.5.2 has issues with schedluer. It's confirmed.

---

I need to rant a bit here, if you'll forgive me.

6.5.2A fixes ONE issue with incremental backups running as fulls the first time after 6.5.2 is applied.  That's it - that's all 6.5.2A fixes if you're already running 6.5.2.  It certainly doesn't apply here...or most of the times people suggest installing 6.5.2A, for that matter.

https://forums.symantec.com/syment/board/message?board.id=21&message.id=45854#M45854

[J_H_Is_gone]

I don't think it is a "version" issue.  I think it was just something hung up when I upgraded that needed to be strightend out.  remaking the policy fixed it.

CRZ - 6.5.2 has never been a problem for me. works great.  any issues I have are "general" issues and version related.  We need to stop trying to blame the version every time.

CRZ you do a good job of helping.  thanks for your support.

[Blazer_2]

Dear Hinchcliffe,

That's why we have to find out the root cause for it. If it not related with version problem, Then what condition should we consider rather than rename or recreate the polices. If it is related to "database" problem, So Symantec should suggest the solution to us since we don't want to lose our backup again....( "user's" data is our main concern when we select the backup solution within the market)

Blazer

[Puffy]

Is the problem solved by recreating the policy ?

[sdo · Accepted solution]

I'd try the suggestion of copying the policy to a new name, e.g. copy POLICYA to POLICYA2, and deactivate POLICYA.  I suspect that the policy execution manager may have become confused and is no longer able to run certain clients in the problem policy name.

I'm curious as to whether you are able to run the "skipped" clients manually.  If you are, then you need to go back to the manuals and ensure that you fully understand how this affects the "schedule window", and that by running a backup manually it is entirely possible and logical that such clients will not run again at the start of the next "schedule window".  i.e. it is quite likely that client(s) will be skipped BECAUSE a manual backup has been run.  Another term that you can research in this forum is "schedule creep" which refers to mis-configured schedules that appear to delay starting backups, or miss/skip them entirely.

If you really want to determine the bottom level root cause then you'll need to raise a case with Symantec Support, as this forum isn't really the place for detailed technical analysis - it's more for quick workarounds to get you going again.

BTW this forum is not an official Symantec support channel.  To post here is to have no expectations of any response whatsoever.  It may be "kindly" hosted by Symantec, but that's it.  It may be frequented, from time to time, by Symantec employees "helping out", which is very kind of them, but don't "expect" a response.

Message Edited by sdw303 on 10-18-2008 12:29 PM

[Blazer_2]

Dear all,

Problem solved by recreation of policy at this moment. I just try to think whether i need to upgrade in 6.5.2A or not.(Since it may cause uncertainty when performing any upgrade)

Regards,

Blazer