Hi @cbaguzman,

Currently there's no way of performing the vhd-cli check command on an encrypted remote, but this is also annoying for us and it shouldn't be too hard to fix, so I'll fix it.

Hi @KPS,

Thank you for reporting this behavior. We haven't been able to reproduce the bug yet, but we'll look into it with @MathieuRA. We're a bit busy at the moment, so we probably won't be able to fix this issue before the November release.

The fix comes from @florent so all the kudos are for him

@jshiells this value is the average load across all cores on a host. To be more precise, it is a weighted average of the last 30min of this value. Migrations are triggered if this average exceeds 85% of the critical threshold defined in the plugin configuration, which is roughly 64% if you defined the critical threshold at 75%.

Other circumstances can trigger migrations :

• if a host free memory is too close to critical threshold
• anti-affinity rules
• if you defined a performance plan behavior other than default (i.e. Preventive or vCPU balancing), migrations can be triggered even when at low memory and CPU usage

Hi @Pilow,

We plan to make LTR available also for mirror backups and metadata backups in the future, but we didn't have the time to do it yet.

Smart mode on mirror incremental backups would be a bit tricky to do, as it would require us to handle incomplete chains of backups, for cases when a tag is removed from a VM and then added back. We might still implement it in the future, though.

About the bug you noticed about VMs showing in backup log despite being excluded, I think it was intentional at some point, but now it would make sense to remove it. Thanks for the feedback, we'll change this.

Hi @Pilow,

This is a great idea, we'll plan it so it gets implemented in the future.

A fix has been merged on master, now the LTR should properly pick the first backup of each day, week, month and year instead of the last one: https://github.com/vatesfr/xen-orchestra/pull/9180

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(backups): long term retention taking the most recent values #9180

@Forza

We plan to make it configurable during the upcoming months.

@Forza said in Full backup - new long-retention options:

Thanks for the quick feedback. Does it mean that the schedule's own retention is also honored separately in addition to the LTR?

Yes, a backup is kept if it matches one of the retention criteria, either the schedule's retention or the LTR. (the backup is not duplicated, we just check for both criteria to know if we should keep the backup or not)

The fix has been released in XO 5.110

Hi @Forza,

I made a fix to prevent the "No new data to upload for this VM" message from appearing if it is only true for a part of the backup jobs of one VM.

It's available here: https://github.com/vatesfr/xen-orchestra/pull/9286

You can test it by switching branch if you're running XO from sources, otherwise you'll need to wait for the next end of month release.

b-Nollet opened this pull request in vatesfr/xen-orchestra

open fix(backups): fix incorrect info on mirror backups #9286

@Forza

Thanks for the details, I managed to reproduce after a few trials.

I'll try to fix it and keep you informed.

@Forza

As the named are greyed-out, could you confirm that the delta backup job saves the backup to remotes srv04-incremental and srv12-incremental, and the mirror backup job copies the backups from srv12-incremental to srv04-incremental? (or at least confirm these are the same couple of remotes)

Also, could you tell me if the VM with which you got the "No new data to upload for this VM" message was backed up by your backup job "Incremental backup every 4 hours - 8 days retention"?

Thanks @Forza,
I'll try on my own with a similar configuration.

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.

Hi @Forza,

Could you send us a screenshot of your backup job configuration so we can try to reproduce?

Hi @k11maris,

I think the situation you showed in your screenshot where both options are selected but are both greyed out should not happen.

We will try to reproduce it on our side and fix it.

Hi @cbaguzman,

We just merged a PR that should allow you to use vhd-cli check on encrypted remotes: https://github.com/vatesfr/xen-orchestra/pull/9235

Please note that, as stated in the PR description, this PR changes the parameters you need to give to several vhd-cli commands, including the parameters of vhd-cli check. You can use vhd-cli check --help for details.

Here's an example of a command I ran on an encrypted remote:

vhd-cli check --chain 'file:///localRemoteEncryptedTEST?useVhdDirectory=true&encryptionKey=%2219876543210987654321098765432109%22' 'xo-vm-backups/695550e5-16e4-4728-6669-ac39e79f19e2/vdis/2656e4f4-efbc-47a6-95aa-0ba88632e545/7a1b144e-1ec8-44e8-9f5e-2d39119a228d/20251125T095729Z.alias.vhd'

b-Nollet opened this pull request in vatesfr/xen-orchestra

closed feat(vhd-cli): accept all types of remotes #9235

Hi @k11maris,

You can either specify the snapshot mode or check the "Offline backup" option.

It's a bit counter-intuitive, but to uncheck it, you can set "Snapshot mode" to "Normal", and you should be able to modify it. (then you can put back the snapshot mode to offline)

Hi @cbaguzman,

Currently there's no way of performing the vhd-cli check command on an encrypted remote, but this is also annoying for us and it shouldn't be too hard to fix, so I'll fix it.