Forum Discussion

trs06's avatar
trs06
Level 5
12 years ago

Netbackup, Sharepoint, GRT with error status 37

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

  • 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

     

14 Replies

  • 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

  • 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
     

  • 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

  • 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