An issue was identified in backup jobs running in incremental with commit 100f113 or release 6.5.0. If one of your incremental backup chains was corrupted, it lead to a cleaning of vdis folder resulting into backup lose.
Please update your source at least to 4552fb9 or your XOA to 6.5.1.
If you encountered issues about a warning with aliases, you are concerned. You need to run your backup jobs again to have your backups back on track.
Hi,
The latest version of XO-lite has an issue, that is why we are temporarily reverting to version 0.19.0. Sorry for the lack of communication on our part.
@itservices Hi,
We did not forget you, working on it!
@Pilow Hi,
Thank you for your reporting! It should be fixed in the next version we are thinking releasing this month if no surprise happens. There is a big refactoring on the clean part which handles metadata (and size) updates.
@Pilow Hi,
Thank you for the report.
We are fixing this in https://github.com/vatesfr/xen-orchestra/pull/9362.
It will be fixed during in a patch.
If you need to install something from hub now, you can get back to Stable branch
@MajorP93 I am currently working on this issue but to answer you quickly, yes we have automatic tests, unit and integration tests (you can see them in *.integ.mjs and *.test.mjs files, and @xen-orchestra/qatest folder), a long QA to validate at each release. We add a regression test at every bug we encounter.
The issue is we could not reproduce your exact issue yet.
@pedro_udifar Hi,
Do you still have errors 500 when you are talking about general errors?
@gsszuber Hi,
Yes indeed, you need to preserve the root of the bucket from Lifecycle. We just had a customer with a similar issue.
Can you help us by giving a small screenshot of the field to filter out the root (or filter in the three folders) please?
@bogikornel are you talking about another issue? We are on an issue specifically on "pool metadata backups". It seems you are talking about VM backups. If yes, can you send the backup log please?
@MajorP93 Hi,
Thank you, thank you! I think you found it! It seems to be SMB, @acebmxer can you confirm that you also use smb please?
If this is the case, the bad news is I think we will need to update our docs to not advise SMB at all: it was already said for delta but maybe we will have to extend this to all kind of BR 
@pedro_udifar Hi,
You can try again with minPartSize=100000000 indeed. But I would advise you to contact B2 directly. They should have a clearer error to show instead of a 500.
Thanks for your patience and your help
@pedro_udifar This is indeed a particular case. Can you switch xo-server log to debug please? Then we would need the journalctl from your xo-server. You can give it to me through MP if you prefer.
They run once a day @ 03:04 before the normal backup that starts @ 03:10 and they have all run OK since July 8, the failed one reported 8 days ago ( post ~85 )
Hi, just to be sure, are you saying it is working ok apart one task 8 days ago?
@ph7 Hi,
Thank you for your log, can you give me the logs before the backup operation if it happens again?
Another thing to check is the exact time between your XO and your host. Maybe you should resync your clock.
I ask that because it seems XAPI was unavailable before this backup or there was a gap of 5 min between the time the backup started and XAPI actually doing this backup.
Maybe you had a xapi db sync just before this backup, do you make these backup regularly? If it is too often (every 5 min for example), it can struggle to start the backup.
