06-09-2008 03:56 AM
07-01-2008 08:41 AM
Yes, I have Solaris Master/Media Servers and am having issues, mostly centered around two areas
1) Inline tape copies w/ Oracle agents
The nbemm and nbrb processes seem to get stuck in loop as soon as the policy is run. They both suddenly use quite a bit of CPU, as seen by "prstat". Subsequent requests from currently running jobs or jobs that run after the "bad" policy for resources such as tape drives or tapes are not granted. Eventually all jobs grind to a halt awaiting resources.
2) Vaulting from Basic Disk storage units
During the Duplication phase for vault, seems as though after 9 images are copied, I get an error 50, client process aborted. I can restart the vault session and the next 9 images are copied. Duplicating from tapes seems to be unaffected.
07-10-2008 01:37 AM
07-10-2008 09:42 PM
There is bin update for nbpem who fix all this schedules issues which is not going to be part of the 6.5.2a ask symantec for this bin.
regards
09-04-2008 10:47 AM
Just updated to 6.5.2A
Master Solaris 10. No backups ran after upgrade, so backing out of install now. No time to sit on the phone with symantec becuase its too late in the day to risk not running tonight.
If you have any fix for this, or something other for me to check that be great. No errors durring install.
Thanks much,
Brent
09-04-2008 03:16 PM
@Kenneth Hansen wrote:Hi,Anyone had problems patching 6.5.2 on a W2K installastion?What I see is that when installing the patch the installer reports "terminate all backup prosesses antd try again" even if al prosesses is terminated... I have this problem on more than one W2k server..
Message Edited by Kenneth Hansen on 06-09-2008 03:57 AM
O
In answer to the original question....
I had this issue.... and solved it...
it seems that when you do the install on windows the wininstall puts its "working" files on the drive that has the most room... NOT always C:
on my server S: had the most room (320 gig free)... problem was that S: was a shared out drive.....
they wanted me to take the share off ( could not it was it a prod server).
so to work around it
(my cd's were copied to disk). I went to the install files into the PC_Clnt/x86 and did an edit on "slientclient.cmd"
modify the the last line, and add to the end
ROOTDRIVE = C:\
removed any files in C:\temp that were leftover from the first try.
I saved the file and ran the install again.... this forced the install to build its temp files on the C drive, and it worked just fine.
when done, I took that part out of the file so it was back the way it was.
Just an FYI in case anybody looks at this for the original error.
09-11-2008 07:44 AM
09-11-2008 07:51 AM
When I first upgraded I had that issue on a couple of policies.
but I just deactiviated and reactiviated the policies and from then on they have run fine.
Sorry I can't give you any more info.
09-12-2008 07:06 AM
Your environment sounds very similar to ours. Solaris 10 master server, 6.5.2A and now an engineering fix for issues with nbpem. The onlydifference is we ae not havng jobs skipped.
I am assuming that jobs are not failing with some status code, but instead they are simply not being launched. If that is in fact what is happening I would consider two possible causes.
You may need to update the OS patches on your master server. Check for core files, they could help diagnose this type of issue.
The other possible cause that I can think of is your Netbackup installation has become corrupted. Fixing this will require removing the Netbackp packages, and reinstalling Netbackup 6.5 and the 6.5.2A update. Followed by the nbpem engineering binary.
09-12-2008 07:15 AM
Hi Selwyn
Thanks for the reply. The engineering binary supplied did not work and now Symantec are busy compiling another binary that is supposed to be 6.5.3. I will await for that but for now am still stuck on 6.5.1. By the way, I tried the OS patches (windows) and that did not help.
09-15-2008 07:43 AM
I had simillar issues (we have a Windows 2003 environment) with several (non-Symantec related) issues when upgrading from 6.0MP5 to 6.5 and then imediately to 6.5.2 which were eventually solved. What I did see was that the first backups to run took FOREVER to start. Although all is running perfectly now at 6.5.2 I still see delays like this sometimes when I restart NBU on the master.
Symantec have told me - and it makes sense - that this delay is due to nbpem rebuilding its joblist - which in our small environment took under an hour. I was told by the engineer that he'd seen this on a large site to take many many hours. I gues the thing to do is - depending on the numbers of policies & clients you have, ie how big your NetBackup environment is - build this amount of time into your implementation plans. I am not even sure that this is to be treated as a bug and if it will be the same from now on. Since adopting this new philosophy to wait for this rebuild, I have had no troubles at all with 6.5.2.
09-15-2008 07:57 AM
dami,
It was because of the nbpem issues that I went ahead and wrote my own NBU Scheduler (VBScript and Windows Scheduled Tasks). I have a great deal more flexibility - and do not have to mess with nbpem and NO STATUS 196. Now if they would get the Vault issues resolved...
09-16-2008 06:05 AM
Is everyone who is having problems with 6.5.2 running their master server on windows?
We have had issues with 6.5, 6.5.1 and 6.5.2, but nothing at all like what I am reading about here. Perhaps you should all look into switching to a server running Solaris 10 for your master.
Just to give you a breif rundown on our issues:
6.5 -- various issues, required frequent restarts of netbackup to keep the system functioning properly. High CPU consumption.
6.5.1 -- overall much more stable. nbsl daemon would stop running after a few days. Created cron job to monitor and restart nbsl.
6.5.2 -- fixed nbsl daemon. catalog recovery wizard was broken. Engineering binary for nbpem fixed this issue.
09-17-2008 03:44 AM
Selwyn:Solaris version also has issues which Symantec have yet to resolve (IME)...so I'd stick with what you have if at all possible until the fixes arrive.
Tim