@jasonnix I've done extensive testing with this myself, first and foremost, Veeam is the one that would have to support it, not vice versa.

Second, it would be best to use XO for the backups, it's much more fluid and is fully integrated, I've been doing this for some time and it's been excellent in multiple production setups.

I also have tested using Veeam via agents within the VMs themselves (this was just for test purposes, I'd still not really recommend it) and it worked exactly as expected.

Using XO for this is still better though, it's generally faster, easier to setup, more reliable, and much faster and easier to recover from backups.

If you are considering this as a comparison to VMware, it's worth noting that it's not really a positive thing that VMware requires you buy a separate product entirely in order to handle backups.

Wanted to post a quick update, it's been over a week now and the backups have been 100% successful.

Figured as such, but thought it was worth at least coming back here and confirming.

I can confirm this is the case for me too, not a huge deal, but would be kinda nice if it could keep track of the name.

@olivierlambert Yup, I've had exactly that a few times, usually on used boards.

@R2rho if possible, however annoying, I would also take the CPU out and check for pins on the motherboard being bent with a flashlight.

IIRC the templates help define some of the UEFI specs and things like that, generally speaking though using something similar to what you're deploying, even if not the same version (i.e. Ubuntu 20.04 template for a Ubuntu 23.10) should be functional, at least in my experience this has never created an issue.

@Bastien-Nollet Thanks as always @florent

@Bastien-Nollet I somehow missed the email about this.

But wanted to come say thanks on this thread anyway. The update fixed the issue, great work!

@olivierlambert I will give this a shot and report back. It may be a day or so, one of the backups is still running (very large VM over S3 so takes a while) but once it's done I will go back and see if the failures go away.

This is a new one, just updated XOA to 5.107.2 and now my backups are no longer working.

I have support and can put in a ticket, but figured it's better to try here first.

I am getting an error: Fail to connect to any Nbd client on the backups to Backblaze and on my SMB backups I just get a Footer1 !== footer2 error.

What's important here is that it's only about half my VMs, and this is a single host setup, so the NBD client issues don't really make sense to me, unless I'm misunderstanding something about NBD.

Anyone else seeing issues with backups after this update?

Also not seeing anything consistent, not like an issue with Windows VMs in specific, it seems random.

@olivierlambert issue added, it's my first time doing it on GH so apologies if I missed anything or put it in the wrong category.

https://github.com/vatesfr/xen-orchestra/issues/7893

planedrop created this issue in vatesfr/xen-orchestra

closed Add Email Notification For License Issues To Prevent Backup Failure #7893

@Bastien-Nollet Thanks as always @florent

@Danp I haven't yet, I will do that when I have a free moment and report back.

This VM has 8GB of RAM though, and so far it only seems to happen when viewing the console. I've only tested with 1 VM so far, but will try a few more to see if it's the console view of 1 VM causing it.

It's been about 3 hours of not viewing the console and it's stayed connected, so at least that's good news.

I'll try to get back today after checking those logs, just didn't want to leave this thread empty.

Thanks for the help!!

I have a production environment that I moved to 5.110 yesterday, this resolved the backup errors I was seeing, but now I am seeing the XOA disconnect from my hosts periodically.

So far it seems to primarily be while using the Console on a VM, though I am not 100% sure, it was stable all last night and just started happening while I was consoled into a Win10 VM.

Going into the servers tab and just disconnecting and reconnecting fixes it each time, but it's still odd so I figured I would report it.

@Bastien-Nollet I somehow missed the email about this.

But wanted to come say thanks on this thread anyway. The update fixed the issue, great work!

@Bastien-Nollet Thanks for the suggestion, though I think I am going to avoid doing that in a production setup.

I'll look forward to it being included in a newer version.

Our backups run nightly and it's random which VMs fail with this error, but so far it's almost never been the same one each night, so at worst we are 24hrs behind on a single VM backup which isn't a huge deal.

Our other nightly backup job to S3 works just fine too so we're covered.

Thanks!

@olivierlambert This is a production setup, rather than my lab, so I don't want to use anything that has a chance of being unstable.

Do we know what version this change may end up in? I'm happy to try the Latest channel if/when this fix is in place.

Apologies if I am misunderstanding anything.

@olivierlambert @florent wanted to post an update here. I upgraded to 5.108.1 in this environment and my SMB backups are doing the same thing with the error just being Footer1 !== !Footer2

It seems about half of my backups fail, so it's not all VMs.

I will try to watch it tonight to see if it's possibly a concurrency issue where it's doing all of them at the same time instead of taking my 2 concurrency setting in place.

Let me know if you want any additional info and I can also submit a ticket.

Wanted to post a quick update, it's been over a week now and the backups have been 100% successful.

Figured as such, but thought it was worth at least coming back here and confirming.

@ravenet Yeah another night of successful backups so I think going back to Stable did fix the issue. 2 for 2 on that now.

@ravenet All of my errors seemed related to NBD access, so if the concurrency setting was being ignored, that might be the source of the issue I was seeing.

I'll watch my lab as well and see if the concurrency is being respected or not on the latest from the sources build.

Glad to see you were on 8.3, so not related to me being on 8.2.