Client backup was not attempted because backup window closed.

[Richard_P_]

I'm getting multiple 196 errors at 11:59:59 even though the Start Window is set for 5:30pm - 5:00am the following day.

We're using 7.6.0.4 Master, Media, and all clients. Last night, it was both VMs and a few physical Unix boxes. Schedules are Frequency Based.

I've read a few tech notes that stated this problem was resolved in previous versions. I'd appreciate a pointer to a solution.

[Nicolai]

You can checkout whats "hot" for Netbackup 7.6 at the Late Breaking News - incuding tech alerts and EEB's.

http://www.symantec.com/docs/TECH199999

and if you are using appliances

http://www.symantec.com/docs/TECH145136

[Nicolai]

This is what I was able to find about the issue. But affected version is netbackup 7.5.0.4 and not the 7.6 branch

http://www.symantec.com/docs/TECH189216

http://www.symantec.com/docs/TECH205108

[Marianne]

Since you are on the latest NBU 7.6 patch level, best that you log a Support call without delay.

Point Support Engineer to http://www.symantec.com/docs/TECH190338 

A workaround is to use Frequency schedule in the meantime.

[Andrew_Madsen]

What is the system time of the master server, media server, and clients?

[Richard_P_]

Thanks for the links Nicolai. I've read thru a couple of those docs... seems the recommedation is for Frequency Based Backups, which we are already using.

System time syncs via a NTP server. Nothing is in another time zone, so it's not a clock mismatch.

Problem didn't occur with our bi-weekly Fulls, which run over our every other week, three-day weekends. (Schedule exclusions in place for our holidays, so Differentials didn't run last night.) We'll see if the problem repeats itself tonight.

Our contract for support is with a third party.

[Mux]

Richard, please keep updating us with the status of this issue...

[Richard_P_]

No problems with the backups last night.

I also found the time to look thru the logs for the weekend Fulls and the only issue was with a couple of Audit Files Backups (they run every night as a separate Policy to a unique Volume Pool) that had the same message. But in this case, it was a valid error. (Tape drives were probably all active with other jobs at the time.) I adjusted the Start Window to give these Policies some additional time to start up, so I doubt they'll be a problem in the future.

I still don't have a clue why the original problem occurred, but for now, I'm writing it off as a one-time hickup by NetBackup.