10-06-2011 06:52 PM
Running a clustered 7.1.0.2, with two Windows-based Media Servers and active/passive PureDisk 6.6.1.2 EEB 20.
Recently our backups are failing with error code 2074 when backing up to PureDisk. Backing up straight to tape is no problem.
We've also Image Cleanup jobs that appear active for more then half a day but eventually end up failing with error code 174.
I've opened a system down case with Symantec Support and sent them GB's of logs but so far they've been unsuccessful determining the cause of the issue. I suspect the Image Cleanup jobs are triggering the backups to fail, but can't tell for sure.
Has anyone run into this issue before?? ANY help is welcome.
10/4/2011 1:16:34 PM - begin
10/4/2011 1:16:34 PM - Info nbdelete(pid=4332) deleting expired images. Media Server: servernbu01.domain1.local Media: @aaaab
10/4/2011 1:16:34 PM - Error nbdelete(pid=4332) Cannot obtain resources for this job : error [2074]
10/4/2011 1:16:34 PM - requesting resource @aaaab
10/4/2011 1:16:34 PM - Error nbjm(pid=7408) NBU status: 2074, EMM status: Disk volume is down
10/4/2011 1:16:34 PM - Error nbjm(pid=7408) NBU status: 2074, EMM status: Disk volume is down
10/4/2011 1:16:34 PM - end ; elapsed time: 00:00:00
media manager - system error occurred(174)
Solved! Go to Solution.
10-14-2011 08:57 AM
We have gone through all versions up to the current V2
I found that the other two PROXY settings did not help and when removed, along with the BUFFERS files removed and the keep_alive settings done it resolved it
I have also found an improvement in performance (massively for GRT duplications) by reducing the fragment size to 5000MB.
Also tuned on de-dupe compression (client and media server side)
10-07-2011 01:12 AM
Try the command in the path "NetBackup/bin/admincmd/nbdevquery -listdv -stype AdvancedDisk -U" and check the status of the volume.
If the status is down run this command in the above path to up the disk volume.
nbdevconfig -changestate -stype <Disk Type> -dp <Disk Pool Name> -dv <Disk Volume Name> -state UP
10-07-2011 01:29 AM
I encountered this on the N5200 appliances and it was resolved with a couple of changes:
Dont use SIZE or NUMBER DATA_BUFFERS_DISK files (dont know if this applies to you system)
Set the keep alive times:
# echo 510 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 3 > /proc/sys/net/ipv4/tcp_keepalive_intvl
#echo 3 > /proc/sys/net/ipv4/tcp_keepalive_probes
You do not to make these persistent
You need only one touch file :
/usr/openv/netbackup/db/config/DPS_PROXYDEFAULTRECVTMO
If you have DPS_PROXYNOEXPIRE and DPS_PROXYDEFAULTSENDTMO get rid of them.
If you dont have DPS_PROXYDEFAULTRECVTMO then create it with a value of 800 inside it.
Hope this helps
10-14-2011 06:17 AM
I tried to solve the problem following Mark's advice, without luck :(
I had the same problem with the 1.1 NB5200 sw version, solved with this TECHNOTE:
http://www.symantec.com/business/support/index?page=content&id=TECH156490
Now we have 2.0 version (equivalent to 7.1.0.1 version of NetBackup). Which sw version do you have on you appliance, Mark?
Tkx!
10-14-2011 08:57 AM
We have gone through all versions up to the current V2
I found that the other two PROXY settings did not help and when removed, along with the BUFFERS files removed and the keep_alive settings done it resolved it
I have also found an improvement in performance (massively for GRT duplications) by reducing the fragment size to 5000MB.
Also tuned on de-dupe compression (client and media server side)