Initially appeared to be working. Client was discovered from the server (after giving server a hint, because of different subnet due to client being connected via OpenVPN TUN). Initial backup was initiated from server end manually, started up fine, but failed part way through due to lack of permissions on a symlink it was trying to follow. Corrected the client backup path so that it was defined with -f option so as not attempt to follow symlinks. Walked away for a few hours, planning to try another backup after having lunch.
Came back and attempted to manually start a second backup attempt. initiated this backup from the server end. Failed. Looked closer at server’s UrBackup “Status” screen and found server thinks client is offline. Attempted to manually start a backup from the client end, this failed too (client status shows not connected to a UrBackup server). Server host OS can ping client IP, client host OS can ping server IP, these two OS’es are talking to each other just fine. Restarted urbackupbackend on client, no change, client still appears offline to server.
Client: LinuxMint 18.1, compiled UrBackup client from source, latest client version (downloaded today)
Server: Raspbian Jesse on a Raspberry Pi3
Other clients work just fine, and installation on these other clients was done identically to the client that is not working.
What to do?
I think I found the answer, or at least a workaround, to the issue.
I had deleted the “client discovery hint” where I specified the IP of the client (over the VPN). My thinking was that once the server had discovered the client, as it had already done, there was no more discovery needed. I thought the UrBackup server would then remember the client that it had discovered. Apparently that is incorrect. Once I re-added the client discovery hint, the UrBackup server updated the client status to “online” and I was able to successfully start a backup manually.
So apparently, if a client is on a different subnet than the server, you need to leave a client discovery hint enabled permanently.
2 Likes
Hi,
Is this behavior “Normal” ?
Why the server doesn’t try to rediscover/reconnect an offline client without the need of creating a “client discovery” foreach client not in same subnet ?
Is a broadcast address working instad of an entry for each client in discovery ?
Thanks a lot
Leaving the discovery hints indefinitely isn’t normally required. The server usually maintains a connection once the client is connected (even if the discovery hint is removed).
For whatever reason, there are scenarios where the server drops the connection when the discovery hint is removed - I haven’t figured out why and when this happens.
If running urbackup inside a jail/container, it could be that the jail is blocking broadcast traffic. I haven’t been able to confirm this, but it’s my suspicion
I think it is because the server can’t dynamically configure a port on the host to listen for a response when it sends the broadcast.
So for the host you also need to permanently open for incoming 35623/udp
If i do that, it works on my setup.