Netbackup 7.1 Client-side Deduplication Fails Status 83
Updated: 19 Dec 2011 | 8 comments
This issue has been solved. See solution.
I'm testing client-side deduplication and am getting Status code 83 failures. I had an open case with Symantec open on this before and we did some troubleshooting, but never got it resolved and went back to media server deduplication. Most of the troubleshooting steps involved checking resolution and port communication between the client and the media server.
The Master server is a Sparc64 Solaris running NetBackup 7.1. The Deduplication Media server, where the MSDP is stores is a Windows 2008R2 SP2 x64 running NetBackup 7.1. The client is a Windows 2003 Server (32-bit) running NetBackup 7.1.
The following is from the job activity:
12/14/2011 09:48:54 - Info nbjm (pid=11872) starting backup job (jobid=61878) for client gabor, policy Windows-EVA, schedule Weekly_Full
12/14/2011 09:48:54 - Info nbjm (pid=11872) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=61878, request id:{82456C86-2673-11E1-B008-00144F81E4DA})
12/14/2011 09:48:54 - requesting resource hsphxmdd01-pd
12/14/2011 09:48:54 - requesting resource wayback.NBU_CLIENT.MAXJOBS.gabor
12/14/2011 09:48:54 - requesting resource wayback.NBU_POLICY.MAXJOBS.Windows-EVA
12/14/2011 09:48:56 - granted resource wayback.NBU_CLIENT.MAXJOBS.gabor
12/14/2011 09:48:56 - granted resource wayback.NBU_POLICY.MAXJOBS.Windows-EVA
12/14/2011 09:48:56 - granted resource MediaID=@aaaag;DiskVolume=PureDiskVolume;DiskPool=hsphxmdd01-pd;Path=PureDiskVolume;StorageServer=hsphxmdd01;MediaServer=hsphxmdd01
12/14/2011 09:48:56 - granted resource hsphxmdd01-pd
12/14/2011 09:48:56 - estimated 0 kbytes needed
12/14/2011 09:48:56 - Info nbjm (pid=11872) started backup job for client gabor, policy Windows-EVA, schedule Weekly_Full on storage unit hsphxmdd01-pd
12/14/2011 09:48:57 - started process bpbrm (pid=6876)
12/14/2011 09:48:58 - Info bpbrm (pid=6876) gabor is the host to backup data from
12/14/2011 09:49:03 - Info bpbrm (pid=6876) reading file list from client
12/14/2011 09:49:04 - connecting
12/14/2011 09:49:06 - Info bpbrm (pid=6876) starting bpbkar32 on client
12/14/2011 09:49:07 - connected; connect time: 0:00:00
12/14/2011 09:49:10 - Info bpbkar32 (pid=6220) Backup started
12/14/2011 09:49:10 - Info bptm (pid=3016) start
12/14/2011 09:49:10 - Info bptm (pid=3016) using 262144 data buffer size
12/14/2011 09:49:10 - Info bptm (pid=3016) setting receive network buffer to 1049600 bytes
12/14/2011 09:49:10 - Info bptm (pid=3016) using 124 data buffers
12/14/2011 09:49:11 - Info hsphxmdd01 (pid=3016) Using OpenStorage client direct to backup from client gabor to hsphxmdd01
12/14/2011 09:49:20 - Critical bptm (pid=3016) sts_open_target_server failed: error 2060022 software error
12/14/2011 09:49:20 - Critical bptm (pid=3016) failure to open proxy target server hsphxmdd01: plug-in reports error 2060022 software error
12/14/2011 09:49:28 - end writing
media open error (83) And the following is from the client's nbostpxy log:
09:48:40.093[4384.7624][DEBUG][61878:bptm:3016:hsphxmdd01][log_corelib]libsts claim_server_dir() 11/12/14 09:48:40: opening plugin directory C:\Program Files\Veritas\NetBackup\bin\ 09:48:40.093[4384.7624][DEBUG][61878:bptm:3016:hsphxmdd01][log_corelib]libsts claim_server_dir() 11/12/14 09:48:40: opening plugin directory C:\Program Files\Veritas\NetBackup\bin\\ost-plugins 09:48:40.093[4384.7624][DEBUG][61878:bptm:3016:hsphxmdd01][log_corelib]libsts openp() 11/12/14 09:48:40: opening module C:\Program Files\Veritas\NetBackup\bin\\ost-plugins\libstspipd.dll 09:48:41.078[4384.7196][DEBUG][dummy][StorageServerImpl::StorageServerImpl]init object StorageServerImpl 09:48:49.109[4384.7196][ERROR][dummy][61878:bptm:3016:hsphxmdd01]pd_register ERROR PdvfsRegisterOST for hsphxmdd01 failed (22 Invalid argument) 09:48:49.109[4384.7196][ERROR][dummy][61878:bptm:3016:hsphxmdd01]add_mount PdvfsMount failed, server hsphxmdd01#1 (5 Input/output error) 09:48:49.109[4384.7196][ERROR][dummy][61878:bptm:3016:hsphxmdd01]libsts opensvh() 11/12/14 09:48:49: v11_open_server failed in plugin C:\Program Files\Veritas\NetBackup\bin\\ost-plugins\libstspipd.dll err 2060022 09:48:49.109[4384.7196][ERROR][dummy][61878:bptm:3016:hsphxmdd01]cp_open_target_server 11/12/14 09:48:49: fail to open sts server 1: PureDisk:hsphxmdd01, return value: 2060022 09:48:49.109[4384.7196][ERROR][dummy][61878:bptm:3016:hsphxmdd01]libsts opensvh() 11/12/14 09:48:49: v11_open_target_server failed in plugin C:\Program Files\Veritas\NetBackup\bin\\libstspicp.dll err 2060022 09:48:49.109[4384.7196][ERROR][61878:bptm:3016:hsphxmdd01][StorageServerImpl::openTargetServer]sts_open_target_server failed, sts return 2060022 09:48:54.375[4384.7556][DEBUG][dummy][StorageServerImpl::StorageServerImpl]init object StorageServerImpl 09:48:54.375[4384.7556][INFO][dummy][StorageServerManagerImpl::openServer]succeed to get the reference StorageServer object. 09:48:54.390[4384.7556][DEBUG][dummy][StorageServerImpl::StorageServerImpl]init object StorageServerImpl 09:48:54.390[4384.7556][INFO][dummy][StorageServerManagerImpl::openServer]succeed to get the reference StorageServer object.
I'm most likely going to open another case, but wanted to check on here in case anyone else may have already found a solution. The short and long (FQDN) names are in the \windows\system32\etc\hosts file of the media server and the client. They're also in the /etc/hosts file of the master, and they can all ping each other with no packet loss. Note: this also happens with my 64-bit clients, too.
Discussion Filed Under:
Comments
Can you upgrade to NBU 7.1.0.2
Most issues with client side dedupe have been solved by upgrading to 7.1.0.2.
Also key factor is name resolution, but I guess you have already tested that.
Hi AlanTLR, I would
Hi AlanTLR,
I would recommend working with support on this one. The clue is here:
As the registration itself is failing, we may need to increase the debug level on nbostproxy log so that it will spit out the exact arguments during pd_register call. Skarve is correct about considering 7.1.0.2. Support can help you eliminate the environmental issues.
Warm regards,
Abdul "Rasheed" Rasheed
Thanks. Increasing the
Thanks. Increasing the debugging log helped. I noticed a config file that was referenced and inspected it. The config file pointed the ost to the wrong interface of the server, despite my having directed the client and media server configuration to the preferred interface. I changed the hostname in the 'C:\Program Files\VERITAS\NetBackup\bin\ost-plugins\<media-server-name>.cfg' file and it got past where it wasn't working before. It still errored out with status 83.
But at least it's further than where I was and I have additional info for opening a Symantec case.
Thanks. I've downloaded the
Thanks. I've downloaded the 7.1.0.2 update and applied it on the master. 7.1.0.2 update was also applied to the media server and the client. I increased the logging on the client and with the same 83 status:
A couple of things here
A couple of things here -
Firstly the client must never be at a higher netbackup release that the media server
Second check out the netbackup proxy service on the client is set to manual startup, and not using a specific account - leave it as local system
Hope this helps
Authorised Symantec Consultant
Don't forget to give a "Thumbs Up" or mark as "Solution" if someones advice has helped you.
The Netbackup client is the
The Netbackup client is the same as the master and media server. The NetBackup proxy service on the client has been verified as being manual startup as 'Local System'.
HiJust noticed these in the
Hi
Just noticed these in the logs:
262144 data buffer size
receive network buffer to 1049600 bytes
I found on a Symantec N5200 appliance which used MSDP that using ans SIZE or NUMBER DATA_BUFFERS really caused it issues and it ran best when left at the defult (i.e. no data buffer files at all)
I also found that for GRT duplications the storage unit needed a fragment size of 5000MB maximum to get any sensible rate of duplication (unlimted fragement size when running an exchange GRT duplication took 24 hours - 5000MB fragment size did it in just over an hour)
It is worth trying without you network and data buffer files and see what happens
Authorised Symantec Consultant
Don't forget to give a "Thumbs Up" or mark as "Solution" if someones advice has helped you.
Any firewalls here? For
Any firewalls here?
For client side de-dupe you will need ports 10102 and 10082 open from client to Media Server i believe.
Authorised Symantec Consultant
Don't forget to give a "Thumbs Up" or mark as "Solution" if someones advice has helped you.
Would you like to reply?
Login or Register to post your comment.