Status 26 for Exchange 2010 after DAG IP changes back from DR site
We've had Exchange 2010 and Netbackup in place for a long time and all has been well. BUT on a couple of occasions, the DAG will change to the IP of the DR site (for reasons unrelated to Netbackup). We don't have Netbackup installed at the DR site (by design) so I understand why it fails then. But once we get things reconfigured as they would be normally, backups continue to fail w/ a Status of 26 for maybe 30-60 minutes, and then begin working again on their own.
I'd like to try to understand what's happening here, even if there's no other option than to wait.
We have an all windows environment w/ Netbackup 188.8.131.52. Exchange 2010 using DAG w/ 4 Mailbox servers (3 in the main site, 1 in the DR site). The DAG has two IP addresses (1 for main site, 1 for DR site).
Once we get it failed back to the main site, I've done the following:
- changed DNS for the DAG. Then flushed DNS on the Master Server, and confirmed that it gets the correct address. The jobs are using the Master Server as the Media server too.
- And eventhough I didn't expect any results, since the server isn't even connecting to the DAG to begin with, I changed the "Database Backup Source" in the Policy from "Passive copy and if not active copy" to "Active Copy only".
I ran a bptestbpcd -verbose -debug -client <client hostname> and it failed when the backups were failing, then succeeded once the backups did as well. That didn't surprise but one thing in the output stuck out, in case it's pertinent. The failed attempt reads "vnet_async_connect", which the successful one reads "vnet_pbxConnect". I attached a copy of the output.
Anyways, if anyone has any thoughts as to what's happening, it would be appreciated.
try running bpclntcmd
try running bpclntcmd -clear_host_cache
"Each cache entry has a life span of one hour, for both successful and unsuccessful resolution attempts, to suppress the otherwise repeated lookups. Accordingly, NetBackup may not recognize any changes to /etc/hosts or DNS for up to one hour."
Article URL http://www.symantec.com/docs/TECH136792