@frank-s yes please the more detailed the bug report is, the easier it is to fix

Workaround found here https://xcp-ng.org/forum/post/94626 Seems like turning "Use NDB to transfer disk if available" switch ON and save backup job, then turn the switch OFF and save backup job again, will fix the issue. Thanks to @RobWhalley and have a nice day everyone.

@DwightHat I am using xoa from sources and i updated it to the latest commit which seemed to fix it for me..

hmm, I found the solution, after I read here on forum. I enable this options and save and then disable and save and now is ok. Task is running again. It is running with last commit to So the problem is with these settings which may not exist in the task created before the update. [image: 1751377404079-05b77f69-6e87-49d2-9c62-d795a13d161a-image.png]

fixed in commit fcefa

Excellent!

Hello, I am asking XO team.

some news on these , we did some test and clearly if proxy lost connection we loose all the info.

I have wondered this myself. [image: 1750783454921-screenshot-2025-06-24-124344.png] { "id": "0mcapon47", "properties": { "name": "Schedule sequence", "userId": "dbf49297-78e4-48c1-a996-a159343f89fe", "type": "xo:schedule:sequence", "progress": 67 }, "start": 1750780800006, "status": "success", "updatedAt": 1750782845608, "end": 1750782845608 } [image: 1750783475725-screenshot-2025-06-24-124427.png]

@florent Expected: Backup A (disabled) run first Backup B (disabled) will run after Backup A Backup C (disabled) will run after Backup B Outcome: All three backups ran in sequence as expected Thank you Florent for the help here

Excellent news, thanks for the feedback!

Sorry I don't see any error, it's just a message from the GC. However, I have to admit I don't have time to take a deeper look myself. If you have support, might be the right time to open a ticket, alternatively someone will take a look when they can

@olivierlambert xe vdi-forget uuid=c6853f48-4b06-4c34-9707-b68f9054e6fc xe sr-scan uuid=6b24cd1c-22ad-0994-5b6b-a75389a6ddba xe vdi-list uuid=c6853f48-4b06-4c34-9707-b68f9054e6fc params=sr-uuid sr-uuid ( RO) : 6b24cd1c-22ad-0994-5b6b-a75389a6ddba yup, that worked, thanks

@florent Thank you.

Thank you for the update. Last night before I saw your replys that is exactly what i did. I purged the backup's for the two VMs from BackBlaze. The backup job completed successfully while copying over the previous backup images. [image: 1749549311956-screenshot-2025-06-10-055256.png]

Thanks @olivierlambert and @florent, that seems to have been the trick and fixed the issue.

@lsouai-vates Is this a description of the cause of the problem ? From what you describe, if one selects a backup containing a LVM partition scheme, it should be able to be mounted at least the first time ? As in here: I verified that this machine is using LVM first, and when selecting it, I immediately selected the large LVM partition to try to restore a file from that (which failed). [image: 1748956125525-e7148e43-aa01-433d-8af4-a936e30550e6-image.png] The machine (Debian 12) running XO do not itself use LVM, so "ubuntu-vg" should be free for mounting this first time.

This happens to me on 8.2 with one specific VM. It doesn't always happen but about once a week (it feels like) the backup will get stuck in Starting and it's always, or almost always, the same VM it's stuck on. I usually reboot the VM running XO and that makes the backup task change to Interrupted and then the next scheduled backup usually works. Would be nice to know if there's something that's causing this that I can try to fix. Not a world-ending problem but it's a nuisance since it stops all future backups for that Job until it's resolved. I'm happy that all the other VMs in that job get backed up at least.

I created a new CR job for another VM and it worked. However, it didn't work with the XO VM. So maybe the root cause of the problem is that the old CR copies have disappeared. Maybe they still exist, but I can't find them?