@CJ this is now fixed with the last commit 74ff6. Thanks to @julien-f

Hi,

i updated Xen Orchestra from sources to commit 0f00c.
And i started a backup job for the XO config this stopped with an error message.
Then i tried the export of the config over the settings this resulted in an empty pop'up and no starting download.

Hope this is useful:

Ubuntu 22.04 LTS (up to date)

nodejs --version
v18.19.0

npm -v
10.2.3

Used XCP-ng version 8.2.1

The Message i get on a backup job for the XO config:

Error: Cannot destructure property 'client' of 'token' as it is null.

Export job error message:

xo-server[5007]:   ERROR HTTP request error {
xo-server[5007]:   data: undefined,
xo-server[5007]:   error: TypeError: Cannot destructure property 'client' of 'token' as it is null.
xo-server[5007]:       at Tokens._unserialize (file:///etc/xo/xo-builds/xen-orchestra-202401050947/packages/xo-server/src/models/token.mjs:16:13)
xo-server[5007]:       at file:///etc/xo/xo-builds/xen-orchestra-202401050947/packages/xo-server/src/collection/redis.mjs:119:24,
xo-server[5007]:   fn: ''
xo-server[5007]: }

@olivierlambert
I tested this now a bit more. And now it works with the traffic limiter.
Your last updates have optimised the backup system too much for my NFS storage
and with that froze somehow the timeout (XO is running on local storage).
And you are right it is doing it per VM, but i think this was in an older version the other way around (wich would be more important to me, but not for others ).

But it would be great if i could get somehow an evenly distribution of the full backups .

@arvid To get a successfull build you need 4GB of ram.
But you could use a pre-build docker container, that would use less memory.

@olivierlambert
Thanks for the quick reply.

For now i use wondershaper to limit the load from the backup, so it can run in the background (not perfect but it works).

Is the "Timeout" normally meant for the the complete backup job(all machines combined) or for one machine in the backup list?

Hello,

i'm using the latest version from the sources.
The system i use is not very powerful and i can not use it and make backups at the same time (NFS storage is to slow).
Also the time needed to create backups off all machines is just enough to take a few full backups and the rest as delta.

Before the job timed out after the defined timeout and the full backups got shifted.
With that i got an evenly distribution of the full backups.
Now this is not the case anymore and all the full backups getting triggered at once (the "Force full backups" is not checked) and would not be stopped after the timeout.

I also tested it if a single full backup (in a delta job) exeeds the timeout and stops, but it did not.

This also would be helpful:
https://github.com/vatesfr/xen-orchestra/issues/5673

RealKelsar created this issue in vatesfr/xen-orchestra

open Full Backup Interval improvements #5673