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.

@florent and @olivierlambert I think it can wait until XO6. I dont have sperate test servers at the office so if I need to spin up a test machine i may want to back it up for testing but not to cloud backup as its only test. Tagging would make this easy since you have tagging implanted. As a work around i could create separate backup jobs for those less important vms.

@Pilow This one should be doable, I am adding it to our backlog

different platform have different internal , and so different edge case. We are here to help to bridge the gap.

No problem, you are welcome!

@Pilow Double checked. There's no filter in place and no new VM.