@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.

@Bastien-Nollet Thanks as always @florent

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.

@olivierlambert Oh yeah good point, that makes sense.

Well I think I've got all my answers now, thank you!

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 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.

@florent OK gotcha, I figured this was the case.

So best option would be to create a new backup job, encrypt that to a new remote, then go back and delete all the old stuff when ready?

@olivierlambert Oh yeah good point, that makes sense.

Well I think I've got all my answers now, thank you!

@olivierlambert right that makes sense. More so what I meant is, if you have a VM you want to migrate to another host, but that VM has a backup job (and therefore at least one snapshot since the backup jobs require there to be a snapshot at all times), then you can't migrate that VM.

So seems to me like backups and VM migration abilities sort of conflict with each other.

Or maybe there's something I'm misunderstanding here.

@olivierlambert OK this makes sense.

Though it does bring up 2 thoughts:

• If backups require a snapshot to exist, how would one migrate a VM that has any associated backups?
• I think the error should be more descriptive than the CBT error I mentioned above

Thanks for the help here!

@olivierlambert Yes, it does. I should've noticed that, woops.

Is it not possible to migrate a VM with any snapshots at all or?

I'm a little lost on this one, and feel like maybe I'm missing something (went back through some previous blogs posts about CBT but didn't see anything related to this and the error doesn't appear on any google searches).

In my lab, I have a VM I am trying to migrate while powered off and it's giving me the below error whenever I do it.

},
"start": 1762284957343,
"status": "failure",
"updatedAt": 1762284960438,
"end": 1762284960438,
"result": {
  "code": "VDI_CBT_ENABLED",

Any clue what this means? CBT is actually NOT enabled for this particular VDI either.

My XO is on the latest commit (58f02), hosts are all on 8.3 but don't have the most recent patches yet.

What GPU do you have? I thought I read something about NVidia's newer stuff having vGPU without the expensive licensing and hardware. But it's possible I'm just conflating that with the increase in concurrent NVENC encodes.

On the bright side, you can always get a cheap GPU and just do passthrough with it. I do that for my Jellyfin server with a 2060, it's very easy to do in XCP-ng now and works super reliably.

Did a little digging and I don't think I've seen anything about this on the forum before so wanted to post.

Does anyone know how Xen Orchestra behaves if you add an encryption key to a remote after said remote has already been used for unencrypted backups?

I'm planning to start encrypting everything I upload in the near future, if it's as simple as adding a key that's great, but I am guessing it's better to create a new remote (and new bucket) and then just restart all the backups with the new remote?

Or should I re-create the backup jobs entirely?

@DustinB Yeah I thought about doing something like this, but then we are getting into overkill costs lol.

My main point behind this post was to get info on what other people are doing, I presumed most are just relying on config backups and will restore it at the other site if needed, which is fine.

I was just also debating about whether or not I wanted the subnets to match between these 2 sites, since that can create some routing headaches, but should still be doable and would make recovery even faster.

@olivierlambert yeah I do use that feature, so that's very helpful! Should make this all doable.

@Andrew Yeah so I hear you on this, and it all makes sense, I've recovered XO plenty of times in my lab.

But, it still feels more complicated than it needs to be and I feel like there has to be a better solution in place. The idea with disaster recovery sites is relatively quick failover (even if manual). Having to restore XO, then reconnect it to all the servers, reconfigure it's IP addresses, etc... feels like it's more work than it should be to do a restore. Not to mention accessing the other cluster assuming something like complete natural disaster destruction at the primary site.

As for backups, yes, I manage a lot of infrastructure like this, not a noob by any means I promise lol, I'm just trying to improve the way I am going to do this in the future, if possible.

Restoring XOA at another site and then reconfiguring it entirely seems like a lot of work.