Follow

Offsite replication status not reported correctly on Backup Status page

KKB000856

SYMPTOMS

After configuring offsite replication, files are replicated to the offsite server but: -

1) the Backup Status page does not show the replicated files

2) synthetic full backups are not processed on the offsite server

3) "Status last updated" column on Local Servers page is not being updated (this should update every 20 mins while replication is in progress)

 

CAUSE

The local server sends replication status to the VSA web server using a process called curl.exe. For security reasons, the VSA checks the source address that curl.exe is connecting from against the IP and connection gateway that the agent is checking in from. This process can fail due to any of the following conditions: -

1) the VSA web server address cannot be resolved from the agent side

2) web server traffic (usually port 80 or 443) is routed differently to agent check-ins (usually port 5721), so it appears from the server side that the source IP address is different

3) the VSA web server is running on SSL and curl.exe cannot validate the certificate authority (CA)

 

To diagnose the cause: -

1) download and extract this test file to the Kaseya agent working directory (usually c:\kworking) on the local server

2) open a Windows command shell (using cmd.exe) and run this command: -

"<kworking>\curl.exe" -F "fileList=@<kworking>\KOR8E2A.tmp" <serveraddress>/BackupTab/ASPx/postOffsiteFileListing.aspx?agentGuid=<agentguid> -o "<kworking>\OffsiteOutput.txt" --failure-log "<kworking>\OffsiteFailure.txt"

 

<kworking> = Kaseya agent working directory (e.g. c:\kworking)

<serveraddress> = VSA web server address (e.g. http://kaseya.mycompany.com or https://kaseya.mycompany.com)

<agentguid> = agent GUID of local server (this can be located from Agent > Agent Status function (select column Agent GUID)

 

3) review the resulting OffsiteFailure.txt and OffsiteOutput.txt files (if existing): -

- if OffSiteFailure.txt contains "error=60", the problem is related to SSL

- if OffsiteOutput.txt contains "Status not updated due to invalid sources", the connection is being rejected because the source address is different for the curl process compared with the agent check-in

 

SOLUTION

If the problem is with the SSL certificate authority: -

1) download this CA certificate bundle and save to the Kaseya agent working directory on the local server

2) restart the local server (go to Backup > Offsite Replication > Local Servers, click on green circular arrow to restart service)

 

If the problem is caused by "invalid sources" message in OffsiteOutput.txt: -

1) review the full message. Here is a sample: -

Status not updated due to invalid sources - For agent 123456789 expected 192.168.220.3 or 192.168.220.3 but got 84.233.140.146

 

In this case: -

192.168.220.3 is the IP address that the agent is checking in from

192.168.220.3 is the connection gateway that the agent is checking in from (it may be same as the agent IP address if the agent checks in from a local subnet, otherwise it will usually be the external IP address of the router that the agent connects to the internet from)

84.233.140.146 is the source address that the curl.exe process connected from. Because it does not match the agent IP address or connection gateway, the connection is rejected.

 

2) review the network configuration. Possible causes for the mis-match are: -

- the agent checks into the VSA on an internal IP address but the VSA server address resolves to an external IP

- reverse NAT is enabled on the kserver side, meaning that inbound connections over different ports have different source addresses

 

FURTHER INVESTIGATION

If the issue is unresolved, please submit the following information to Kaseya support for analysis: -

 

1) access details for VSA and local server agent ID

2) OffsiteFailure.txt and OffsiteOutput.txt files from the above tests

 

APPLIES TO

Kaseya Backup

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Article is closed for comments.