Hi @Andrew the backup listed in restore (and health check) should be complete. We create an alias to the real vhd directory and this alias is created only after the transfer is finished.
We are reworking the logs to be more precise and visible in the UI, because some of these are not needed anymore (and some are really hard to understand (like the unused message that can be reached by two code paths)
maybe it's more a restore heath check issue. Do you have more details?
@ronivay hi, can you test this branch fix_console_bis before we merge it?
thank you for your report
@ronivay hi , something should not have worked as intended, I'm working on it. Your server is a 7.6 ?
@bberndt are you able to test the fix ?
@stormi at least it failed on 7.1CU2 installed this morning.
I implemented a fallback not checking the version, but catching the specific error message and going back to the old method
@ronivay yeah
I'm making a little code cleanup before merging in master (removing console , adding changelog)
We'll probably make another patch release with this fix.
I'm glad you saw it and give us such a precise feedback.
@ronivay @bberndt Could you try this branch fix_console_proxy_xcp_7x containing a quick fix (fallback for older hosts to the old method)?
from this PR: https://github.com/vatesfr/xen-orchestra/pull/6191
@ronivay that's a great information. I can reproduce the comportment with xenserver 7.1 CU 2
Thank you
@ronivay I did a lot of tests yesterday (master/latest/old and new commit) , with a wide range of xcp and didn't reproduce it
Do you use any http proxy between XO an XCP ? Do you use some kind of network filtering ? do you use xo in HTTP or HTTPS mode ?
@maverick Hi maverick, did you also update the packages ? We did move from aws-sdk2 to aws sdk 3 recently
@Andrew yes , thank you
@JVComputers thank you for helping us fix it
hi @stevewest15 , can you create a support ticket on https://help.vates.fr/ ? Then we will open a tunnel support to look into this in depth
Regards,
Florent
Hi fred,
I looked into your problem and did not reproduced it on our test lab. Have you got a xo support subscription ? That would allow us to open a support tunnel and search a solution more efficiently
Regards
Florent
@s-pam I answered on the ticket and deployed the fix.
@s-pam this issue caused quite a few tickets, which one is yours ? I can connect right away
@s-pam it's a great choice 
If you can launch a backup , I can connect through a support tunnel and deploy the fix
then you can launch the backup and we can celebrate the success of this fix
@pnunn @S-Pam If you use the sources, can you try to use this branch feat-add-debug-backup it's master with additionnal debug and a potential fix ( potential , because I can't reproduce it regularly in our lab)
Then you can activate more debug by this
[logs]
# Display all logs matching this filter, regardless of their level
filter = 'xo:backups'
# Display all logs with level >=, regardless of their namespace
level = 'debug'
in your config file ( should be in ~/.config/xo-server/config.toml
@stevewest15 I don't have any advice of the fiability of b2
Their design require us to make a minor modification to our upload service .
During a full xva backup to a S3 like service, each part uploaded is uploaded along its hash and that is used to control the integrity
thank you @stevewest15
I don't have the info I wanted inside, but I think we'll have to handle the 500 error of b2 with a retry . Theses errors are uncommon on S3, but are here by design in b2
there isn't much documentation online, but I found here ( https://www.reddit.com/r/backblaze/comments/bvufz0/servers_are_often_too_busy_is_this_normal_b2/ ) that we should retry when this error occurs
can you copy the full log of this backup ? It would be easier If we could get a machine code ( probably a http code like 50x ) as explained here : https://www.backblaze.com/blog/b2-503-500-server-error/
You can get it by clicking on the second icons from the left in your job report
