11-20-2012 01:01 PM
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
Solved! Go to Solution.
01-28-2013 02:12 PM
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
11-20-2012 01:21 PM
"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.
11-21-2012 03:31 AM
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
11-21-2012 06:22 AM
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.
11-21-2012 06:35 AM
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
11-21-2012 06:59 AM
#edit - ignore please - entry on wrong thread - sorry!
11-21-2012 07:09 AM
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:
11-21-2012 07:21 AM
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
11-21-2012 07:33 AM
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.
11-21-2012 09:13 AM
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
11-21-2012 11:16 AM
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?
11-22-2012 05:04 AM
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
11-26-2012 10:07 AM
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
01-28-2013 01:37 PM
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
01-28-2013 02:12 PM
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