fix(backup/mirror): don't run healthcheck if nothing as been transferred

[fbeauchamp]

Do not squash

Description

fix healthcheck when no data have been transferred , adding a info for the user

clarifying documentation on healthcheck in case of mirror backups

From : https://help.vates.tech/#ticket/zoom/21585

Checklist

• Commit
  • Title follows commit conventions
  • Reference the relevant issue (Fixes #007, See xoa-support#42, See https://...)
  • If bug fix, add Introduced by
• Changelog
  • If visible by XOA users, add changelog entry
  • Update "Packages to release" in CHANGELOG.unreleased.md
• PR
  • If UI changes, add screenshots
  • If not finished or not tested, open as Draft

[fbeauchamp]

bug is still here : https://xcp-ng.org/forum/post/71850

[fbeauchamp]

fixed https://xcp-ng.org/forum/post/71925

[MathieuRA]

If the PR should not be squashed, write it in the PR description and fix the typo in your last commit name.

IMO, a changelog entry should be added for the healhcheck fix

[julien-f]

There is an architectural issue:

• writers where initially developed to run on a single backup
• this assumption has been broken when re-using the writers for every backups of a VM in mirror backups
• the introduction of _metadataFileName is a kind of global variable which is set to last wrote backup

We should clean this, either using writers for a single backup, and creating new one as necessary, or accepting they are intended to be called on multiple backups and clean up the state as necessary (e.g. passing metadataFileName as parameter to healthCheck).

[fbeauchamp]

• using a new writer each time will lead to healthchecking each backup of a delta chain, and I think it will cause problem for the first transfer, or we'll have to rework the way we call the healthcheck
• In theory, the _metadataFileName can be specific to each writer. In practice it should be the same path for all remotewriters, relative to the remote root. The parameter won't have the same meaning with replication writers. I am not favorable to store this in the runner and use it as a parameter
• the transfer list of mirror backup is computed per remote and may be different, if the user add a new remote, or if a remore failed the previous trasnfer, that means that you can have a healthcheck on a remote, and not on another

As a side note, the current iteration of the backups code comes from the mirror backup feature, 9 months ago https://github.com/vatesfr/xen-orchestra/commits/1005e295b27942fe7986bdbc335ca41f9b400ea2/%40xen-orchestra/backups/Backup.js?browsing_rename_history=true&new_path=@xen-orchestra/backups/Backup.mjs&original_branch=master .

[julien-f]

1. I understand that
2. Fair enough
3. Makes sense

I know the change was done a long time ago but I did not understand/think about the semantic changes implied for the writers.
I don't think there are currently bugs with this but I fear problems in the future.