Video Screencast Help

Netbackup, Sharepoint, GRT with restore error status 37

Created: 02 Jan 2013 • Updated: 20 Jan 2013 | 23 comments
This issue has been solved. See solution.

Hello there,

Sharepoint Backup with GRT enabled completes successfully.

restore failed with error 37, there is no other details about the failure!

we have Symantec Netbackup

Please advise where should i invistigate?

Discussion Filed Under:

Comments 23 CommentsJump to latest comment

RamNagalla's picture


could you give us more detail?

what is the storage unit that you are using for Backups?

form where did you trigger the restore job?

please check the T/N , which give more info about the EC 37

u500302's picture

could you give us more detail?

we have 5 servers for the sharepoint 2010:

front servers: sr1001spw001, sr1001spw002

application server: sr1001spa001

SQL Cluster (virtual server sr1001csql2010): nodes sr1001sql011, sr1001sql012

what is the storage unit that you are using for Backups?

Symantec Deduplication

form where did you trigger the restore job?

from the Master server

u500302's picture

regarding the link you have posted, it is not valid for my case

i do not see the error

Operation requested by an invalid server

RamNagalla's picture

could you provide the restore log from the location /usr/openv/netbackup/user_ops/<userid>/logs

and also bpcd and bprd logs of master server at the time of restore job as attachment.

u500302's picture

Thanks Nagalla for your support, the master and media servers are installed on windows based servers.

can you specify what logs to check?

I believe my issue is in configuring servers list somewhere.

RamNagalla's picture

hi ,

make sure that you have the bpcd and bprd log directories created in master server. I am sure about your master server is Window or Unix

Keep Verobse = 5 

for Unix:-



for windows:-



then open up your java conosle of Master server and trigger the restore job., while click on the restore log, you will have option to specify the Progress log.. 

by default it will be 

/usr/openv/netbackup/user_ops/<userid>/logs --->for unix

Installpath/veritas/netbackup/logs/<userid>/logs  --> for windows

please provide all these 3 logs 

u500302's picture

please find attached logs, please let me know if you have any question.

AttachmentSize 882.24 KB
Mark_Solutions's picture

Have you completed the Distributed Application Mappings section on the Master Servers Host Properties - it says it is for Exchange but it is for SharePoint as well

Hope this helps - will take a look at your logs

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

u500302's picture

Distributed Application Mapping has been configured,

SharePoint front servers are mapped with sql backend and cluster virtual server, and with the indexing server.

Mark_Solutions's picture

Do you have the logs from yesterday when you tried the restore (010213.log) or have you tried it today - if so at what time?

I do see:

14:48:48.374 [7144.5124] <16> is_redirected_restore_allowed: One or more input parameters are invalid.

So maybe it is the Distributed Application Mappings that are needed, the No.Restrictions file on the Master can also help

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

u500302's picture

I have tried the restore one hour or less before i upload the logs.

Distributed application mapping has been configured.

I am not sure what do you mean by the No.Restrictions file.. i have not read about it in sharepoint admin guide, could you please explain?

RamNagalla's picture


From bprd log

01:03:19.077 [6340.2024] <16> free_allocated_resources: Free resource allocations failed.

01:03:19.077 [6340.2024] <2> mail_msg_and_set_exit_status: Attempting to send mail to root on
01:03:19.077 [6340.2024] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1478: 0: in failed cache: 11001 0x00002af9
01:03:19.077 [6340.2024] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1479: 0: in failed cache name:
01:03:19.077 [6340.2024] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1480: 0: in failed cache service: NULL
From bpcd log:-
15:47:38.190 [916.8188] <2> bpcd main: VERBOSE = 0
15:47:38.190 [916.8188] <2> logparams: D:\Program Files\Veritas\NetBackup\bin\bpcd.exe -standalone 
15:47:38.190 [916.8188] <2> process_requests: offset to GMT -14400
15:47:38.190 [916.8188] <2> logconnections: BPCD ACCEPT FROM TO fd = 480
15:47:38.190 [916.8188] <2> process_requests: setup_sockopts complete
15:47:38.206 [916.8188] <2> bpcd peer_hostname: Connection from host ( port 1722
15:47:38.206 [916.8188] <2> bpcd valid_server: comparing sr1001bck001 and
15:47:38.206 [916.8188] <4> bpcd valid_server: hostname comparison succeeded
15:47:38.206 [916.8188] <16> process_requests: read failed: The operation completed successfully.
I dont understand why its using port 1722 to communicate...
do you have firewall in place.. does it configured properly?
Marianne's picture

Perfectly normal - source ports are random. The destination port is the only important one: 1556.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

u500302's picture

I will add more details, this may help

Master server is: sr1001bck001

SharePoint Front servers: sr1001spw001 and sr1001spw002

SharePoint application server: sr1001spa001

SQL servers: sr1001sql011 and sr1001sql012, Cluster virtual server is: sr1001csql2010

Mark_Solutions's picture

On your master server create a file named No.Restrictions (this is case sensitive) under the path:

\program files\veritas\netbackup\db\altnames\

This allows redirected restores when requested from clients - which is in effect how SharePoint works as it redirects the restores to the components of the Farm

If you are not happy to leave it in place just rename it after you have re-tried your restore.

If you could setup a folder named tar under the logs directory on the front end farm server and then re-try the restore telling us the time it started and finished and then re-upload the logs again so that we can pin point the restore and what is happening.

Also note that you should only do restores from the Master Server or the Front End Farm Server

Authorised Symantec Consultant

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

u500302's picture

the No.Restrictions file was created long time ago for SQL backup policies.

I am aware about the source limitations, restore should be run from Master or Front end server.

I am not sure about the tar folder, could you explain more please?

Marianne's picture

We see reference to hostname in bprd log:

14:48:48.374 [7144.5124] <16> is_redirected_restore_allowed: One or more input parameters are invalid.
14:48:48.374 [7144.5124] <2> process_request: client sr1001spw002 peername is invalid for restore request
Where does this hostname fit into the picture?
Browsing was successful - we see many fileslist entries in bprd log.
Restore request is processed:
15:47:01.267 [1744.7232] <2> process_request:   browse_clnt: sr1001spw00215:47:01.267 [1744.7232] <2> process_request:   requesting_clnt: sr1001spw00215:47:01.267 [1744.7232] <2> process_request:   destination_clnt: SR1001CSQL201015:47:01.267 [1744.7232] <2> process_request:   clnt_bp_conf_name: sr1001spw00215:47:01.267 [1744.7232] <2> process_request:   peername:

The final result is that 'centraladmin' is seen as actual destination name. Restore ends with status 48:

15:47:01.298 [1744.7232] <2> local_bpcr_connect: Can't connect to client
15:47:01.298 [1744.7232] <2> ConnectToBPCD: bpcd_connect_and_verify(sr1001spw002, failed: 48
15:47:01.298 [1744.7232] <2> log_to_progress_file: BPCD on exited with status 48: client hostname could not be found

If 'centraladmin' is your Windows Admin Console, please check if 'configured client name' was at any point changed. Important that it must ALWAYS be the local hostname, unless you really want to redirect the restore to this machine. 

Use 'All Programs', Symantec NetBackup -> Backup Archive and Restore window on 'centraladmin', 
Open File -> NetBackup Client Properties.
Check Client Name.
Ensure that it is indeed 'centraladmin'.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

u500302's picture

Hello Marriane,

Sorry for being late, I was in a training, anyway, many thanks for your support.

I have checked Netbackup Client Properties and the Client Name is configured properly (local hostname).

Centraladmin is the SharePoint administration console.

I prefer regenerating the logs and check again, please advise what logs shall I upload here?

Many thanks in advance.

V4's picture

do have beds under logs. (on front end server) . Please elaborate on which content are you trying leverage GRT

Is it from Central Admin or Shared Service Admin WebSite. If yes then just an update GRT are not supported on this sites

Also can you try to execute restore from Front end server with user who has sharepoint admin privileges and   is configured as service account for NBU

Also check if with this account you can see and expand sharepoint resources under BAR

With multiple servers in farm ensure network registry is enabled between front end and back end servers

u500302's picture

Thanks all for your support, the error for case is resolved,

it was a reverse lookup record issue, there are multiple sites that share the same ip address so the netbackup could not locate the correct name.

i have a different error now, however, i will give it a try and if i could not fix it then i will open a new case here.

for this case i will mark Marianne's answer as a solution as she enlightened the central admin issue which guided us to the resolution.

Many thanks again.