Team - XO Backend group | XCP-ng and XO forum

florent

both fixes are now on master AND released as a patch

simonp

I'm taking this issue from Pierre.

Did you perform a full restart of the XCP-ng host since the issue occured ? Or just restarted the toolstask ?

pierrebrunet

@bogikornel @jb @gregbinsd @majorp93
We tested metadata backups every 5 min and it works in XO. It seems it might be coming from XCP-NG, can you provide us a xensource.log from the problematic timeline?

pierrebrunet

@bogikornel Can you tell us on which versions you are please?
the ones where it works and the ones where it does not work.
Thanks for your help!

pierrebrunet

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

pierrebrunet

@pedro_udifar Hi,
We think we have found two issues into one: can you test this branch please? It has the changes from previous branch you built: fix_throttled_stream

This should fix the stream issue and fix the warning.

pierrebrunet

@pedro_udifar Hi, just to be sure, this is a replication job with two s3? If yes, is the source s3 encrypted or is it only the target?

florent

@pedro_udifar that is strange that we have exactly the same error, even though we should have added 28 bytes

I pushed a little debug that will log additional lines in journalctl

'will output stream ', 'stream is encrypted' and 'stream is updated '

Can you update your branch, rebuild, rerun the transfer and post the log ( with the attached values ) ?

regards

florent

@pedro_udifar object lock works quite well with xo
it is automatically detected if the s3 user has enough privilege to see if object lock is enabled

the main point is that it won't create "cache.json.gz" files since theses files must be updated, so the backup listing is a little slower

note that XO retention should be at least 1 more than object lock . At worst you will have error , saying that XO coudn't delete an old backup

The fix is on a separated branch : fix_s3_nonencrypted_to_encrypted_xva ( PR : https://github.com/vatesfr/xen-orchestra/pull/10061 )

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(fs): compute the output stream precisely when encrypted #10061

florent

@pedro_udifar we have found a clue , if the destination is encrypted and the source is not

can you test this branch ? https://github.com/vatesfr/xen-orchestra/pull/10061
if you are using a xoa, we can deploy the fix if you open a support tunnel

fbeauchamp opened this pull request in vatesfr/xen-orchestra

Team - XO Backend

Posts

closed fix(fs): compute the output stream precisely when encrypted #10061

closed fix(fs): compute the output stream precisely when encrypted #10061

Member List