XOA 5.107.2 Backup Failure via SMB and S3 (Backblaze)
-
@ravenet Yeah another night of successful backups so I think going back to Stable did fix the issue. 2 for 2 on that now.
-
Wanted to post a quick update, it's been over a week now and the backups have been 100% successful.
Figured as such, but thought it was worth at least coming back here and confirming.
-
Thanks for keeping us posted, really appreciated here by all the team
-
@olivierlambert @florent wanted to post an update here. I upgraded to 5.108.1 in this environment and my SMB backups are doing the same thing with the error just being Footer1 !== !Footer2
It seems about half of my backups fail, so it's not all VMs.
I will try to watch it tonight to see if it's possibly a concurrency issue where it's doing all of them at the same time instead of taking my 2 concurrency setting in place.
Let me know if you want any additional info and I can also submit a ticket.
-
I think I've read a recent PR about this:
https://github.com/vatesfr/xen-orchestra/pull/8882
Can you try that branch and report?
draft fix(backup) error footer1 !== footer2 #8882
-
@olivierlambert This is a production setup, rather than my lab, so I don't want to use anything that has a chance of being unstable.
Do we know what version this change may end up in? I'm happy to try the Latest channel if/when this fix is in place.
Apologies if I am misunderstanding anything.
-
I don't know, but I can ask @xo-team
-
We'll try to make it available on 5.110 but we can't guarantee it for the moment (I think the PR Olivier linked is more of a temporary fix than a definitive solution).
If you feel comfortable with directly modifying the code of your XO, you can apply this fix just by commenting two lines in a file and restarting xo-server. The lines to comment are these ones : https://github.com/vatesfr/xen-orchestra/pull/8882/commits/51a543df25af1b0069e07f6d9ad2608ed3476e29
draft fix(backup) error footer1 !== footer2 #8882
-
Thanks @Bastien-Nollet !
-
@Bastien-Nollet Thanks for the suggestion, though I think I am going to avoid doing that in a production setup.
I'll look forward to it being included in a newer version.
Our backups run nightly and it's random which VMs fail with this error, but so far it's almost never been the same one each night, so at worst we are 24hrs behind on a single VM backup which isn't a huge deal.
Our other nightly backup job to S3 works just fine too so we're covered.
Thanks!
