Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrade.
Please accept our apologies in advance for any inconvenience this might cause.

Netbackup, Sharepoint, GRT with error status 37

Created: 20 Nov 2012 • Updated: 01 Nov 2013 | 14 comments
This issue has been solved. See solution.

I have searched the web for help with a status 37 error trying to do a granular restore from Sharepoint 2007.  Previously I was able to do this but now, no matter what I try and restore, I get a status 37 with no other information what-so-ever.

I get the following from the client:

"Restore     11/20/2012 2"13"30 PM     Error (37)"

From Netbackup Detailed Status:

"11/20/2012 14:13:30 - begin Restore"

From Netbackup Status 37 troubleshooter:

"An invalid media server or Windows NetBackup Remote Administration Console made a request to the NetBackup request daemon (bprd) or NetBackup database manager daemon (bpdbm). On Windows, these daemons are the NetBackup Request Manager and NetBackup database manager services."

Looking at the frontend host that's in the Netbackup Sharepoint policy there is no "NetBackup Request Manager and NetBackup database manager services"

 

thx

  Terry

Comments 14 CommentsJump to latest comment

Marianne's picture

"NetBackup Request Manager and NetBackup database manager services" run on the master server only.
All restore requests are sent to bprd on master.

Please ensure that bprd and bpdbm log folders exists on the master server. If not, create them and restart NBU.

Retry the restore.
After failure, copy log file in bprd folder to bprd.txt and post as File attachment.

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

Mark_Solutions's picture

From the NBU SharePoint Admin Guide ....

Administer restores from the NetBackup master server or the SharePoint
front-end server.

So there are only two places that the restore should be run from. If you are trying it from anywhere else you will get the 37 error

Hope this helps

Authorised Symantec Consultant

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

trs06's picture

I am looking over the log file now.  I'm confused about the invalid client entries, in fact I'm confused about most of the log entries; why our Sharepoint servers and sites are invalid.  The restore was to same location not redirected.

If a restore of Sharepoint GRT from the Master server then I don't know how.  All attempts I've made to restore GRT have been from the front end server that is listed in the Sharepoint policy.  This is how I have done it successfully previously.

See attached.

 

AttachmentSize
NBUStat37SharepointRestore.txt 5.35 KB
Mark_Solutions's picture

Have you added the No.Restriction file to the netbackup\db\altnames directory?

This allows the friont end server to direct restores to the other SharePoint farm servers

It also says that the requesting server is not valid so add it as an addition server to the Master Servers Host properties - servers tab and also to the client attributes tab and in the browse and restore section set it to allow both

Hope this helps

Authorised Symantec Consultant

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

Mark_Solutions's picture

#edit - ignore please - entry on wrong thread - sorry!

Authorised Symantec Consultant

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

Marianne's picture

Was NBU Request service restarted after bprd log was created? 

I don't see any 'fileslist:' entries. You will see lots of lines starting with something like this while you are browsing in the BAR GUI:

 

.....
16:58:47.293 [17975] <2> fileslist:    timetype = 3
16:58:47.293 [17975] <2> fileslist:    rqtimetype = 4
16:58:47.293 [17975] <2> fileslist:    user_interface = 1
16:58:47.293 [17975] <2> fileslist:    full_listing = 5
.....
 

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

trs06's picture

The front end server and the server to restore from are in the Master Server Properties Server list.  Both servers are in Client Attributes with "Both" checked.  I then ran:

# ./bprdreq -rereadconfig

Re-runing the backup I get the exact same results.

I inspected both the bp.conf on the Master and checked it in the GUI and the changes were made properly.

I appreciate the help.  The backups are running very well with the timeouts now set at 3600.

   Terry

 

trs06's picture

The whole log is 26 MB.  More than I think might be allowed or appreciated in this forum.  I've only sent excerpts.  Attached is from this morning after making the changes advised by:  Mark_S..

See attached.

AttachmentSize
NBUStat37SharepointRestore-2.txt 19.05 KB
Mark_Solutions's picture

The log shows this:

09:16:31.913 [11149] <2> process_request: client appp5010 peername centraladmin.ad.ama-assn.org is invalid for restore request

Do these names tie in with what you have given access?

It does look like SharePoint also uses the districuted Application Mapping in the same way that an Exchange DAG does - so please complete that too as this does only apply during restores (Master Servers Host Properties ... add the front end server against all other servers)

Also, can you confirm that the netbackup client service and netbackup legacy network service accounts on the SgarePoint Servers are using the SharePoint Administrator account?

Have all SharePoimnt clients had their Client Host Properties - SharePoint section completed?

Hope all of this helps

Authorised Symantec Consultant

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

trs06's picture

Yes.  We have one Domain Account for all servers in the farm (5) and the account has local administrator rights on all the boxes and is used to start the Netbackup Services on the Client.  The Windows client - Sharepoint config is also config'ed with the same user and includes the password.  Following are our servers:

5035 - db server

5119 and 5120 - app servers

5010 and 5031 are Frontend web servers

I don't quite understand and the Sharepoint admin guide was'nt totally clear for me how to populate the Distributed Applications property on the Master Server.

Under application hosts I list both 5119 and 5120? and then for component hosts I list the front end web servers and the db server so that I would have six entries there?

i.e.  three entries for each of 5119 and 5120.

5119                   5035

5119                   5031

5119                   5010

then do the same for 5120?

Mark_Solutions's picture

The front end servers are the important ones so you should have

5010 5035

5010 5119

5010 5035

5031 5035

5031 5119

5031 5035

The restores should be done from the Master Server or front end server

It is both the netbackup client service and netbackup legacy network service that needs to be set to your sharepoint account on all SP Servers

Hope this helps

Authorised Symantec Consultant

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

trs06's picture

I'm getting a mismatch error, see below.  centraladmin.ad.ama-assn.org is configured with round robin ip's and seems to always hit appp5031 rather than 5010 thus the mismatch.  I've been told that it has always been that way.  Are we missing some configuration within Sharepoint that is giving us this problem and thus the restore failures?

10:32:43.128 [13148] <2> bpcr_connect_with_vxss: client name mismatch for host centraladmin.ad.ama-assn.org: expected appp5010, got appp5031
10:32:43.128 [13148] <2> ConnectToBPCD: bpcd_connect_and_verify(appp5010, centraladmin.ad.ama-assn.org) failed: 39
10:32:43.128 [13148] <2> log_to_progress_file: BPCD on centraladmin.ad.ama-assn.org exited with status 39: client name mismatch
 

trs06's picture

Here is an excerpt from the bprd log file.  Netbackup appears to be comparing client names and they don't match.  I don't know how this mechanism works or where the information comes from for the comparative. The diference from the above post is that I changed the Netbackup Client in the Policy to our other Front End Server.  Any help with this please?

 

14:52:07.901 [11636] <2> bpcr_connect_with_vxss: client name mismatch for host centraladmin.ad.ama-assn.org: expected appp5031, got appp5010.bu.ama-assn.org

14:52:07.901 [11636] <2> ConnectToBPCD: bpcd_connect_and_verify(appp5031, centraladmin.ad.ama-assn.org) failed: 39

14:52:07.901 [11636] <2> log_to_progress_file: BPCD on centraladmin.ad.ama-assn.org exited with status 39: client name mismatch

Mark_Solutions's picture

The issue you will have is that each client is known to netbackup by its name and IP address and this is cached by netbackup

So if it wants to connect to a server it will get its IP address from its cache and then connect to it, rather than look it up in DNS.

Each component in your farm would need a fixed IP address preferably for everything to work well.

If your backups work OK but restores do not then maybe you just need to do a:

\netbackup\bin\bpclntcmd -clear_host_cache

before running the restore to flush the cached data from the last time it connected

If it is just the virtual name that has issues then the Distributed Application Mappings / No.Restrictions file should help - but if it actuall tries to talk to one server and another server responds i am not sure how to get around that other than clearing the cache

Hope this helps

 

Authorised Symantec Consultant

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

SOLUTION