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

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.

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.

@Pilow

This is supposed to be the first day of the year, of the month, etc... But we just noticed a bug that makes LTR keep backups from the end of month, end of week, etc.

A fix is on the way.

Hi @Forza,

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

Hi @Pilow,

You're indeed supposed to have more backups kept. (probably 9, as the backup of the current week is already kept by the schedule's retention).

We'll try to reproduce the problem on our side to see what's going on and fix it, but it will be a bit long as testing it requires a lot of waiting.

Thanks for the feedback, it will help us improve the feature.

@Pilow I was replying to Forza, who has only one schedule with cron pattern 5 18 * * 0. I edited my message to make it clearer that I wasn't talking of ph7's backups.

What you did seems totally fine to me.
Could you detail a bit more what was unexpected in the results, and share a screenshot of your backup job retention/LTR configuration, so there is no misunderstanding?

@Forza As your backup tasks executes only once a week, the schedule retention is redundant with using "Number of weekly backups kept" of LTR.

If keeping the last 52 weekly backups of this job is what you want, I recommend you to set the schedule retention to 1, and the number of weekly backups kept to 52. This way, if you happen to execute this backup job manually (in addition to its schedule), it will not delete the oldest backups.

Hi @Pilow,

This is not possible at the moment, but it's a feature we plan to add in the following 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)

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.