Great job, worked perfectly! Thank you very much for your fast support!

@Pilow error reporting is a feature in itself . Thanks

@Pilow I will take a look in deep later, but the key/delta and disk usage is set during backup, even if they are merged during LTR retention

@Bastien-Nollet Great, thanks!

@Forza you will have to switch to LATEST to profit from end month release STABLE is one version behind LATEST both are production ready.

okay weird. Let's see if there's other reports then

I hope someone will reply to my post here about how to check status on this but I believe I've resolved the main issue: I disabled and re-enabled the whole task itself yesterday and it ran this morning as scheduled.

@henri9813 yes thank you for correcting my message

I confirm that this is the current behaviour, as @pilow reported here https://xcp-ng.org/forum/post/99446 We might change it in the future to make it better, but it won't be trivial to change.

@MajorP93 aha, yea. Per disk concurrency is important too.

Adding @florent and/or @Bastien-Nollet in the loop

Adding @gregoire in the loop

I will tell you a little secret, you taught me more than that one command for CLI lol One more important note for my Bitwarden Thanks again bud!

Hi @jshiells, After some tests, I don't think it can be caused by the load balancer. If the load balancer tries to migrate a VM that is being backed up, the migration instantly fails and nothing happens. Reversely, if a backup job starts when a VM is being migrated by the load balancer, the backup will fail for that VM with error "cannot backup a VM currently being migrated".

https://forums.veeam.com/kvm-rhv-olvm-pve-schc-f62/xcp-ng-not-showing-as-virtualization-source-after-restore-t101040.html Et voilà suffit de demander

@Pilow You might be right, this may be simpler to implement than we imagined. We'll keep you informed when we progress on this.

Thanks @Pilow for the test

For completeness sake. Confirming that the fix also works in my second lab as well.