Client 2.2.5 backups failing on Server 2.2.11 (was 2.2.8, then 2.2.10)


#1

Upgraded recently to the latest version of UrBackup. Have the Urbackup version 2.2.8 server installed on a Windows 2012 R2 VMware VM. Many of the client versions don’t show on the status screen (see screenshot), thought they show that they are online.

I’ve been collecting debug logs for the last few days. Lots of clients show this way. If I try manually creating an image, it will show that “Starting backup failed”.

When I stopped the UrbackupClientBackend windows service and changed the logging to debug and then restarted the service the backups would start for one cycle. Then they started to fail again.

I’ve got the logs if they are needed.

Cheers


#2

yes yes , post the logs


#3

I’m a little hesitant to do that in the open for security reasons.


#4

Is there a place to upload logs securely? I can’t seem to find anything on that.


#5

Maybe post only some parts with errors.
And If you have notepad++ just do a search and replace all of the server /client names, maybe some folder names.

If you want to upload a lot of things then maybe
Use a 7z with a 20 chars and numbers password
Upload it somewhere.
Then either PM the password and link or just post them on the forum.


#6

Okay, I’ve got them cleaned up (thank you for the idea of notepad++).UrBackupLogs.zip (167.8 KB)


#7

The server seems to spam :

2018-03-28 20:58:46: Sending Identity to client “-- CLIENT COMPUTER NAME REMOVED–” failed. Retrying in 60s…
2018-03-28 20:58:46: Connecting to ClientService of “-- CLIENT COMPUTER NAME REMOVED–” failed: Sending Identity to client “-- CLIENT COMPUTER NAME REMOVED–” failed. Retrying soon…
2018-03-28 20:58:46: Sending Identity to client “-- CLIENT COMPUTER NAME REMOVED–” failed. Retrying in 60s…
2018-03-28 20:58:46: Connecting to ClientService of “-- CLIENT COMPUTER NAME REMOVED–” failed: Sending Identity to client “-- CLIENT COMPUTER NAME REMOVED–” failed. Retrying soon…
2018-03-28 20:58:46: Sending Identity to client “-- CLIENT COMPUTER NAME REMOVED–” failed. Retrying in 60s…

Could it be because of network issue or because the communications need some key that is missing:

network :
By default urbackup will need to be on the same network that the client and by this it means that udp broadcast have to work for a set of ports (in the docs).
If that’s not the case, you need to set internet mode.

keys:
And the server ident file should have the server key inside, if you reinstall the server, or have 2 servers, it may fail because of this (need to manually add the key for any server after the first one that connected to the client).


#8

All clients and the server are on the same IP network. Can ping either direction just fine, so I don’t think it’s that. I do get some clients getting backups, and it seems to work after restarting the UrbackupClientBackend service in windows. This all started after upgrading to 2.2.8 from 2.2.7. I’ve never had an issue before upgrading, so not sure if it’s related to the upgrade.


#9

Try disabling the firewall on the client, to see if that causes it


#10

Firewall is disabled on all clients via AD GPO.


#11

Hate to be a pest, but wondering if there’s any more input anyone can provide. The latest update seems to have broke everything for me.


#12

Bump, still getting this issue. Should I reinstall clients? I could push them out via GPO with the MSI.


#13

Can you downgrade a client to 2.2.7 make sure?
Remove the urbackup folder in program files after uninstalling (because of the local db of the client that you can t downgrade)


#14

I usually let the server upgrade the clients, so the most recent installer in a lower version I have is 2.1.16. Won’t this just immediately upgrade the client? Should I turn this off to test backup functionality? Thanks for the tips. I’ll give this a go tomorrow.


#15

Yes disable auto-upgrade if u have it


#16

On a test client: Uninstalled, removed Urbackup folder in program files, removed client from Urbackup server GUI, installed MSI version of 2.1.16 on client, added client to Urbackup server GUI and fired a full image backup. It’s working as expected now. I’ll see if in the next few days this particular client does the normal full/incremental backups that I have scheduled.


#17

Over the weekend it attempted to perform incremental backups on the test client. All of them failed within about 20s. Would a reinstall of the server help? Can I keep all my settings and existing backups (which are about a month stale at this point)?


#18

Hi

You may, but i doubt that would change anything.
Could you have like a firewall that goes into protection mode and automatically blacklist ip that transfert too
much?
Also , it s still in 2.1.16 and it still failing,with the same error?


#19

Sorry for the late reply. I’ve been working on a few other things. So, I wanted to correct the record. The server that hosts the UrBackup Service does have a firewall setup with inbound rules for the UrBackup executable. All protocols, ports, etc. are set to “Any”.

There are literally no entries in the “Windows Firewall with Advanced Security” event logs other than some Veeam entries from doing backups of the machine (it’s a VM).

The test client I’m using is still on the old version 2.1.16. When trying to run a full image backup, I get the same error of “Starting backup failed”. I went to take a look at the logs and realized I had turned off the debug level of loggin. I re-enabled the debug logging on the client and then restarted the UrBackupClientBackend service and then doing a full image backup starts as expected. This is the same experience I had with the 2.2.5 client version, which makes me wonder if it’s the server that’s causing the issue. Not sure what I can do to get back to a working instance of UrBackup now.


#20

Just upgrade to server version 2.2.9 and seem to have the same issue. To be clear, if I restart the client service I can run a full image backup from the server control panel. I’ll have to see in the next few days whether the scheduled backups occur as scheduled, or if they fail.