@Dezerd To check if there is perhaps a hung process that is interfering. I assume there is sufficient memory and storage space. DO any I/O disk errors show in /var/log. SMlog ? Just to clarify. are there VMs that do not show any such error condition?

Thanks for the feedback @norpan , worth it! Ping @florent

@pedro_udifar Hi, You can try again with minPartSize=100000000 indeed. But I would advise you to contact B2 directly. They should have a clearer error to show instead of a 500. Thanks for your patience and your help

Got this issue since 2026-07-12.

@Bastien-Nollet Perfect, thanks Bastien! Thanks for looking into this, I really appreciate how responsive everyone at Vates is on this forum.

@pierrebrunet said: Hi, just to be sure, are you saying it is working ok apart one task 8 days ago? Yes, after I adjusted the time it's working

@simonp , thank you very much and all of your team ! ! ! Keep up the outstanding work. Regards, Marc

@christopher-petzel Thanks!

Indeed, it should be detected/reported correctly to avoid losing time finding the problem. Let me ping @julienXOVates

Ping @julienXOVates

Ping @julienXOVates

@Pilow pretty much

@pierrebrunet ticket created https://help.vates.tech/#ticket/zoom/59723

@poddingue Since setting NBD=1, I have not seen the problem. SR is NFS on dual 40G ethernet with a TrueNAS scale 25.10 server using all NVMe SSD, so storage performance is as good as I can make it. I'll have to enable NBD=2 again to see if it still happens and if I can find the relevant part of the logs. As this is a random problem I can't recreate it on a normal test environment.

Pilow's right that moving a VM to another SR forces one full pass while the CBT bitmap is rebuilt; that part is expected. But your screenshot actually shows the likely culprit for the all-VMs-fall-back-to-full pattern: you have Purge snapshot data when using CBT enabled, and XO's incremental backup docs flag exactly that combination as a known issue where you can occasionally get unexpected fulls: https://docs.xen-orchestra.com/xo5/incremental_backups#known-issues. It might be worth running a few jobs with that toggle off to see if the deltas hold. It is a known rough edge on the CBT side, so following the central CBT feedback thread and maybe a nudge to @Team-XO-Backend wouldn't hurt.

@henri9813 said: Hello, I see also this behavior which is "new" since few weeks. Previously, when a backup start: it stake a snapshot ( if there another one before, it delete it ). it upload the snapshot as a backup it coalesce the backup on the remote. end of the game. Now, the old snapshots are not deleted anymore which can lead easily to some disk full. Even with a retention of 1, the problem is present. I observe this only in Backup job, not DR/CR job. I just updated my XO to latest version, i will see if the issue is fixed. Hi @henri9813 , Issue should be resolved in 6.5.x, can you confirm on your side ? Thanks!