@pierrebrunet Hi Pierre, I really appreciate you taking the time to respond here.
Noted on the ‘unused XVA’ explanation. So the unlinked metadata is not necessary for VM recovery from a backup exhibiting this warning, right?
As for the ‘XVA might be broken’ warning, this draws some concern. For every single backup I run, atleast 1 or more VMs exhibit this message. I just ran a manual backup of all my VMs today, 4 out of 12 of them had ‘XVA might be broken’ attached to them, even for completely idle Rocky Linux web app servers. Surely users can't be expected to just continuously run subsequent manual backup jobs because of this message? What would potentially cause the compressed XVA to become corrupted? And why can't said-corruption be validated in any practical way outside of “just running backups again”?
Constantly running backups and hoping the ‘XVA might be broken’ warning doesn't show, and constantly validating past backups who had this message attached to them all sounds incredibly time-consuming. Shouldn't backups bring peace-of-mind, not hours worth of unplanned validation work? Yes of course any good admin should periodically test their backups, but doing so as often as each time this message is shown seems entirely impractical.
