I upgraded from 6.5.2 to 6.5.2a to resolve
the issue with queued backups failing at midnight when their window is open
past midnight. As of right now, it looks like that is still very much an
issue. I’ve got a load of backup jobs that fire at 8:00PM Friday night
with a 2 day window. As of midnight, anything in a queued state failed with
error 196. Guess I’ll be re-opening the case with Symantec. /sigh.
I haven’t been able to perform any
VCB backups yet, but according to the support engineer 6.5.2a was supposed to
have a few fixes for that as well.
-Jonathan
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Haskins, Steve
Sent: Saturday, July 26, 2008
12:03 AM
To:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] 6.5.2 &
6.5.2A BEWARE!!!
All; especially
Windows Netbackup admins,
I upgraded my
Windows test Netbackup 6.5.1 environment to 6.5.2 then 6.5.2A. Problem
with 6.5.2 in Downing a drive in that it would down the wrong drive. 6.5.2A no
problem (test environment again).
I upgraded my
production environment this past week from 6.5.1 to 6.5.2A and PEM would not
start so obviously scheduled backups would not start and I had to roll back to
6.5.1 which was painful. Two media servers I had to uninstall/reinstall
Netbackup server software and reconfigure.
Found one
case on the web where another peer had the same problem. I opened a case with
Symantec and they strongly advised me to not install 6.5.2 and just wait for
6.5.3. this fall instead of trying to correct 6.5.2A. As reported to me the
main fixes in 6.5.2A were to resolve admin console issues which I have
experienced.
FYI, if you get an
error message stating to close all processes and try again when updating or
rolling back a MP rename the Netbackup.dll in the
%installpath%\Netbackup\Bin
folder as long as no other processes besides standard Netbackup services are
running.
Regards