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

If you still have the problem, you can increase the healthCheckTimeout value as Olivier recommended (e.g. healthCheckTimeout = ‘30m’), however this value should be in the [backups.defaultSettings] section of the configuration file (or in the [backups.vm.defaultSettings] section) rather than in the [backups] section.

We've detailed the documentation a bit to make this more understandable: https://github.com/vatesfr/xen-orchestra/blob/a945888e63dd37227262eddc8a14850295fa303f/packages/xo-server/config.toml#L78-L79

As Mathieu answered in this topic, the bug has been reproduced on our side but isn't trivial to fix. We'll discuss with the team to schedule this task, and we'll keep you informed when it's fixed.

You are right, the documentation isn't up to date, this isn't configurable at the moment.

We are currently working on the load balancer, so this may come in future versions.

I made a fix for this: https://github.com/vatesfr/xen-orchestra/pull/9228

I'm not that familiar with disaster recovery, I'll discuss your point with the team.

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

open fix(xo-web): allow offline delta backups #9228

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

@Pilow You might be right, this may be simpler to implement than we imagined.

We'll keep you informed when we progress on this.

Hi @Pilow,

We might improve this in the future, but for the moment you'll have to create two different schedules, one for the day with healthcheck, and another one for the six other days. Then, create two different sequences, one for each schedule.

Hi @Forza,

The first list is the correct one.
For instance, a single backup can satisfy both the monthly and yearly criteria.

Hi @Pilow,

This is not possible at the moment, but it's a feature we plan to add in the following months.

Hi @Forza,

The long term retention is independent of the retention of the schedule: even with a backup retention of 1, the long-term retention will keep some backups separately.
Note that the LTR applies to every schedule, so it may be preferable to use it with a single schedule.