21/6/26 i upgraded urbackup-server 2.5.36.0 to 2.5.37.0.
One client (my biggest rig) started throwing the error since the first backup performed since that upgrade. The client is version 2.5.31.0, it looks like that is the current latest.
8/7/26 another client started to complain about the same thing.
I vaguely remembered seeing similar errors (but regarding metadata length/checksums) when i was experimenting with the number of hashing threads months ago, so i had another look and it seems for both these clients the number of threads is set to the default, the global advanced settings show this and i remember only experimenting on individual clients (and even reverting them). Both clients do not have an advanced setting overridden in their respective individual (advanced) settings (a padlock next to them). These are the global advanced relevant settings:
Both clients do not use any snapshotting mechanism. Up till this date i had good results without it (on any client for that matter). In the past i did experiment with btrfs snapshotting, but i got fed up with finding snapshots not being removed after successful backups and did not experience any performance upgrade. So until recently, the logs only showed warnings for files like those qcows that they were changed during backup, like e.g. /var/log/syslog and the likes, but the backups never failed. Also the qcows arent even on btrfs anyway (to prevent write amplification) and are on ext4. The bulk data is on btrfs, so if i need a snapshotting mechanism, i should use that.
So, of course i searched around on the forum for that error, nothing. I tried setting the “Beta: Number of parallel client file hash threads per file backup” to 1 instead of the 2, same result.
The result atm is that both hosts are failing their backups (entirely!) and the mechanisms in place to shut down the backup server keeps thinking there is a backup in progress, in fact i just now noticed the for “serverddlin7” there are plenty:
Another peculiar thing thing is: this only happens when the virtual machine is in use (the qcow is opened) and the qcow is stored on local storage. I have 3 other virtual machine instances that have their qcow files on a “glusterfs” and those are also running 24/7, but those backup fine. I just chose a machine with the glusterfs mounted and specify that as a backup path for that client. This is what it looks like in the log (as it did before with the others):
-i have removed the section regarding the trouble i had with managing virtual clients, long story short i concluded that adding a virtual client name in the webgui works almost directly and can be seen on the client itself in the output of urbackupclientctl list-backupdirs, but also in the web gui under clients and the pull down where you can choose a client, but when i removed a virtual client name on the server side i had to reinstall the client software to force that change, later i found that when removing a virtual client name it can take about an hour for that change to take effect on the client itself. Its not a big issue nor relevant so i cut that from this post-