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.

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

Ok, thanks for the information.

I think I saw somewhere a bit of code that saves the value of 'Offline backup' so users don't have to re-check it if they go back to full backups, but it shouldn't interfere with delta backups.

I'll investigate this and keep you informed.

Hi @k11maris,

I just noticed I originally misread your message, you were already talking of the 'Snapshot mode' option I mentioned.

Could you send us a screenshot of the backup job configuration?

Hi @k11maris,

I reproduced the same behaviour, but I think this is perfectly normal.

If you want to only do an offline snapshot and restart the VM while the export is happening, you should uncheck the 'Offline backups' option and set 'Snapshot mode' to 'Offline'.

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

Hi @jshiells,

Sorry for not answering earlier, Pierre wasn't working during the past weeks.

I'll soon investigate on how the load balancer interacts with backups.

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

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

Thanks @Pilow for the test

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

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