Failed Backups: Windows backup component config XML is empty

Since upgrading to client 2.1.15 and server 2.1.19 I’ve had one desktop client that stopped backing up successfully (full or incremental). The logs show the error “Windows backup component config XML is empty”. If I change “Windows components backup configuration” in the server settings to “default=0” then the backup completes.

I know this one machine does have an sqlexpress instance that was installed as part of another software package. I don’t care if the database gets backed up or not as it doesn’t contain anything I care about so I am content leaving “default=0”. I manage all my settings from the server, so I haven’t even touched the client.

Is this a bug or a configuration error?

There is probably more information in the client log file so have a look at that if you turn it on again.

This is the contents of the client’s debug log for yesterday. It attempted a backup 4 times. The logged backup times on the server are 9:07, 10:32, 12:34, 15:53. The last one was successful after setting default to zero. The only errors I see are the CUDPThread messages.

2017-03-20 08:05:25: ERROR: Recvfrom error in CUDPThread::UdpStep
2017-03-20 08:05:25: ERROR: Last error: 0
2017-03-20 08:15:13: WARNING: Limiting number of DC users to 105
2017-03-20 08:26:53: WARNING: Limiting number of DC users to 105
2017-03-20 08:31:38: ERROR: Recvfrom error in CUDPThread::UdpStep
2017-03-20 08:31:38: ERROR: Last error: 10058
2017-03-20 09:47:16: WARNING: Limiting number of DC users to 105
2017-03-20 09:50:39: WARNING: Limiting number of DC users to 105
2017-03-20 11:53:00: WARNING: Limiting number of DC users to 105
2017-03-20 11:56:06: WARNING: Limiting number of DC users to 105
2017-03-20 13:25:21: ERROR: Recvfrom error in CUDPThread::UdpStep
2017-03-20 13:25:21: ERROR: Last error: 10058
2017-03-20 15:15:05: WARNING: Limiting number of DC users to 105
2017-03-20 15:15:06: WARNING: Restarting shadow copy of c:\ because it was started by this server
2017-03-20 15:15:08: WARNING: Restarting shadow copy of c:\ because it was started by this server
2017-03-20 15:15:08: WARNING: Restarting shadow copy of c:\ because it was started by this server
2017-03-20 15:15:08: WARNING: Restarting shadow copy of c:\ because it was started by this server
2017-03-20 15:15:08: WARNING: Restarting shadow copy of c:\ because it was started by this server
2017-03-20 15:18:26: WARNING: Limiting number of DC users to 105

I have 3 out of 35 clients with the same error. It started on 3/16/2017 which is when I believe the clients updated to version 2.1.15. Server version is 2.1.19.

The client computers are Windows 7. They all seem to have windows components, but not Exchange, MS SQL or Hyper-V which are the ones that “default=1” should backup.

One of the client has: Task Schedule Writer, VSS Metadata Store Writer, Performance Counters Writer, SqlServerWriter, COM+ REGDB Writer, Registry Writer, WMI Writer

Around the same time I also enabled groups for these clients, two of the clients are in different groups.

Going into the Group Settings, Advanced and setting Windows components backup configuration to “default=0” instead of “default=1” fixed the backups.

Errors in the client logs were similar to to davton’s errors. I do not have UrBackup configured with LDAP so not sure why I see the limiting of DC users.

While I was able to fix this with setting default=0, I like the default setting trying to backup the main components. However, would it be possible to check if the main default components aren’t there, but others are, they are backed up or ignored and there wasn’t an error? This was causing the backups to fail, not just throw an error.

Could be they also have Microsoft SQL Server Express instances. Some applications embed them. If possible you could enable debug logging on one of the clients and then send me the debug log after a failed file backup.

See here for details: Having problems with UrBackup? Please read before posting

A customers win7 PC with MS-SQLexpress has the same issue.
any news on that?

  • client: 2.1.16 (win7)
  • UrBackup Server v2.1.19.0 (armhf, debian)
  • the client’s debug log was sent to bugreports@urbackup.org

and there is no C:\Program Files\UrBackup\enable_debug_logging.bat in that installation. you might adapt your how-to, you mentioned. april 20th.

@uroni any news on that quite serious issue?

Sry, got around to having a look at the log file. Could you try if preventing the file symlinks helps?

That is exclude C:\ProgramData\Oracle\Java\javapath\java*.exe