Unsolved
This post is more than 5 years old
89 Posts
0
3096
SharePoint plug-in issue(s)
I'm trying to get this plug-in to work and not having much luck. We have a backup network where all of the SP servers, FE and BE and SQL all have IP's in; however when I run an SP backup I get the following errors, this is just a snippet below, but that '192.168.10.150' address is not the backup IP, that's another IP on the SP server, the primary IP. I read somewhere in the SP guide, way below, about using "only the primary NIC", I just wanted verification if indeed the SP plug-in could only use the primary nic or if there was a way to use a "backup" network that's running on non-primary nics? Would make my life much easier if you could force another network. Thanks.
...Unable to connect to the back-end client '192.168.10.150', error code: 2. Please ensure that the back-end backup agent is running...
...The back-end client "dns-name-of-192.168.10.150" will be dropped later in the process....
...[My-SP-Front-End] is unable to forward CTL sub-workorder to [backend-client-192.168.50.150..
From SP Avamar Guide:
Backup can fail when farm servers have multiple NICs or IP addresses A backup can fail when WFE servers or back-end servers have multiple NICs, multiple IP addresses, or both. Network load balancing can cause the back-end client to see the WFE server's secondary IP address instead of the primary IP address. In that situation, Avamar might report an error similar to the following: Client refused browse request. 10007 Unable to connect to the back-end client '', error code: 2 Please ensure that the Back-end backup agent is running. To fix this error, use the Windows command line to add an avagent.cmd file and persistent routes to both clients: 1. Add an avagent.cmd file with --netbind= on both clients. 2. On both clients, use the Windows command line to add persistent routes that use only the primary NIC for outgoing traffic routed to the Avamar system.
Rino
6 Posts
0
September 21st, 2017 06:00
Hello Daryn,
this issue might be due to a timeout problem so let's first apply flag "--vss-snapshot-timeout=600" as explained in the KB article below:
KB 453150 - SharePoint 2013 farm backups failing with "Unable to connect to the back-end client"
https://support.emc.com/kb/453150
If the above it will not help, meaning we are not in that scenario the we can try out the following option:
On Front-End server
(the one we use to run backups from):
- Create the "avmossvss.cmd" file in the plugin /var folder (usually c:\Program Files\avs\var)
- Add the flag "--static-address-list" like in this example and save the file:
--static-address-list=HOSTNAME(IP_ADDRESS)
where:
* HOSTNAME is the BE hostname as seen from the Front-End
* IP_ADDRESS is the IP address of the BE client to connect to the backup network
If you have multiple back end clients with the same connectivity issue then add them all as in this example below:
--static-address-list=HOSTNAME_1(IP_ADDRESS), HOSTNAME_2(IP_ADDRESS), HOSTNAME_3(IP_ADDRESS)etc...
On Back-End server
(the one that we can't reach from the front-end):
- Create the "avmossvss.cmd" file in the plugin /var folder
- Add the flag "--static-hostname-list" like in this example and save the file:
--static-hostname-list=DNS_ALIAS(HOSTNAME)
where:
* DNS_ALIAS is the DNS alias as seen from the Front-End
* HOSTNAME is the actual name of the machine
Note: this is in the event each Network will be linked to a different DNS alias on the same BE server (typically on SQL server).
Run a new SharePoint backup and check the results.
Finally if with the use of the flags the backup is still not working I recommend to open a ticket with the Avamar support team who will further assist you.
Clarkson14
89 Posts
0
September 21st, 2017 14:00
Thanks, this looks to be clearing up my errors so far; the one I'm running into now is the errors about OSearch14 writers not running on the backend servers, but I figure I just need to get my SP admin to turn those on.
One thing I think I'm having problems with is my SQL server, it's a cluster with an instance for the SP DB's; I see the below errors in the avagent.log file on the Avamar SQL shared folder's /var directory, though I've noticed I don't see any individual logs for each SP job attempt like I see on the other servers where you get a log per job, not sure if I have a bigger issue there with the SQL cluster and SP in general I need to solve first. Appreciate the help.
2017-09-21 16:49:09 avagent Info <14800>: The WinDNS DnsQuery() method returned a mixed result set. DNS record 2 result type 1 does not match expected type DNS_TYPE_PTR
2017-09-21 16:49:09 avagent Info <6624>: Attempted connection from non-localhost IP address - my_front_end_backup_ip:55755 != '127.0.0.1'
2017-09-21 16:49:09 avagent Info <10684>: Setting ctl message version to 3 (from 1)
2017-09-21 16:49:09 avagent Info <16136>: Setting ctl max message size to 268435456
Clarkson14
89 Posts
0
September 22nd, 2017 06:00
Well, on the SQL front I had stumbled across this KB article, trying to figure out if there was anything SP/SQL related, this didn't really fit the problem per se, but I tried "Resolution 2", about adding the avmossvss.pin entry for the --pininclude flag, and oddly I tried a backup and the SP backup communicated with the SQL back-end and started backing up the DB's.
One question I had though, for some reason I thought I had read that the SP plug-in, when it backs up the SP databases it doesn't mess with the normal SQL backup chain, but we're transitioning from CommVault where our SQL and SP backups are still located, when it ran it's next differential it threw a warning that it was switching to a full because a backup had been done using another product, obviously Avamar. Not sure if that's expected or I've got something else misconfigured.
Article Number 000468551
https://emcservice.force.com/CustomersPartners/kA2j0000000R6KOCA0
Rino
6 Posts
1
September 26th, 2017 01:00
Hi Daryn,
I am glad to see you made progress on it and now the issue is resolved.
Regarding your last concern, I believe we both agree that having two backup tools in place running Incremental backups would affect the DB chain log and as a consequence a new full backup is required, therefore it is never a good idea to have two tools backing up the same SQL system around the same time.
With that said, there are different case scenarios that may be happening in your environment, please take a look at the following KB articles, I hope they will clarify the concept of "log gap" and you may find them useful somehow:
KB 453582 - SQL backup Error: A log gap was identified or a full backup was not found - forcing a FULL backup.
https://support.emc.com/kb/453582
KB 495081 - Avamar SQL differential backups got promoted to full for some clients/databases
https://support.emc.com/kb/495081
KB 426780 - SQL database backup failing at specific time every night
https://support.emc.com/kb/426780
KB 456171 - Avamar: Last full backup time on the SQL server does not match any snapups
https://support.emc.com/kb/456171
Note: some of those KBs might be for an older version of Avamar or might not fully apply to your case so keep them has a general rules and/or as a theoretical knowledge sharing.