I worked around this issue by changing my full backup job to "delta backup" and enabling "force full backup" in the schedule options. Delta backup seems more reliable as of now. Looking forward to a fix as Zstd compression is an appealing feature of the full backup method.

I had to disable Purge snapshot data when using CBT. Backups are not longer defaulting to full backups.

Just connect your XOA to your dedicated network and it will flow to it.

@olivierlambert Host started and issue resolved.

@olivierlambert Thanks that worked. Kind of obvious approach, still didn't try that

Are you sure the job isn't already running, as per the error message?

Backup job still failing. I have open a support ticket - Ticket#7746281

@stevewest15 I believe this issue was resolved when the health check system was changed to detect network connectivity at startup so it did not need to wait for then entire VM to boot. Needs the Xen tools to be installed. I have not had an issue since this change.

This look great! Something I was missing. But unfortunately I get an authentication error as well. I do not get it running. I am using PowerShell 7.5 and I am using a cert that is singed by my own CA. This CA is included in the Windows cert store for trusted root certificates. With all browser this works fine. Hopefully someone has an idea?

@olivierlambert minor update... its now been 48+ hours and task is still in the same state, not timed out yet.

Since I'm not used to using git, I was running a few tests on my "test" host. I had made a change in my "one line commando" My memory is not in best shape so I forgot the change and ran it in my update. Now It's sorted out and ran a new update and voila

@olivierlambert Here's the new model. We've tried a few combinations and I think with TrueNAS shared storage this will now work well. [image: 1759787234216-f78178c0-3330-4233-8f9b-debc3c61a3e9-image.png]

@lsouai-vates

@acebmxer said in Veeam backup with XCP NG: and when not accidentally routing the backups... save 6 min.. [image: 1759373010653-screenshot-2025-10-01-224148.png] host [image: 1759373021630-screenshot-2025-10-01-224223.png] Amazing, that's really impressive. Backups has always taken a long time with XOA once you start to backup a lot of VM's so I hope this will improve the overall backup performance

@Pilow I thought restarting tool stack affected both host? Either way did try that but on host 1 originally. So i restarted on host 2 (where problem is). still no locked. I rebooted host 2 and that seem to do the trick. Took a few min for garbage collection to complete. All clean now. Thanks.

@farokh one backup job should leave one snapshot. this is the way. to differentiate from previous backup the data to be put in the delta, it has to refer to this snapshot. delete it and you get a full backup ongoing. if you have two snaps on your VM, either you have a manual one, or you have multiple backup jobs backuping this VM (check the backup tab of the VM ?)

@olivierlambert that is a discrepancy between what was planned ( a vm delta backup) and what we can do with the data available ( a full ) . In this case, it's only one disk that fell back to full We have to improve how to show the information with mixed state

Probably in a next release (before the end of the year ideally)

@yaroz it loosk like there is an issue with some error not stopping the job as expected, I am currently working on this In the meantime , you can restart XO , it will forcefully close all running jobs

I had to bring the VM offline and do a VM copy, now the new one can snapshot/backup.