@Pilow said in Veeam backup with XCP NG:

@olivierlambert I get you.

Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.

would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.

Giving better observability is something we are working actively on , this is tightly coupled with being able to stop a task, and I hope we will be able to show the progress soon

@manilx yes, that's it

we should change the "full backup interval" to "base/complete backup interval", to clarify what is a full . And we will do it.

we are reworking the import code , along the new backup code ( https://xcp-ng.org/forum/topic/10664/our-future-backup-code-test-it ) to unify the differetn disk transformation path

For now:

• V2V handles flat, cowd, sesparse, stream optimized vmdk in the format "metadata.vmdk and a data file ) and ova ( for VSAN)
• disk import support monolithic vmdk ( cowd, sesparse, streamoptimized )
• ova improt support only stream ova with streamoptimzed vmdk inside

@andrewreid Yes, I can't wait to share it with everybody.

@Andrew then again, with such a precise report, the fix is easier

the fix should join master soon

found it , there was not one, but 2 bugs
albeit small they were putting the xo backup in a incorrect state
the fix is here, and will be merged as soon as possible and then released as a patch for xoa users
https://github.com/vatesfr/xen-orchestra/pull/8780

really thank you everyone for the information

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(xapi): respect the config file setting for preferNbd #8780

@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation

@RobWhalley nice work, I am testing it right now

@olivierlambert Nice catch
CBT will only be enabled when using purge data , I will fix the first one

(this is because CBT does not improve things without purge snaphot data , but has some edge case , so at least we won't enable it for nothing )

@olivierlambert @Gheppy that is a nice catch and it gives us a interesting clue

I am currently working on it

@MBNext is it possible to post the full json (you can download it on the top of the windows that shows the backup progress )

@MajorP93 the size are different between the disks, did you modify it since the snapshots ?

would it be possible to take one new snapshot with the same disk structure ?

@Pilow said in Veeam backup with XCP NG:

@olivierlambert I get you.

Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.

would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.

Giving better observability is something we are working actively on , this is tightly coupled with being able to stop a task, and I hope we will be able to show the progress soon

@Pilow said in Veeam backup with XCP NG:

@flakpyro thank you

@florent , would be nice to add this to XCP backup ? merge progress

You can check the toggle "merge sychronously" in the advanced block of the backup job, to at least know when the merge is done

(we intend to make this the default choice in the near future)

nice
I think they compute speed as "disk size / time" , whereas we compute it as " used data / time"

That's great to have more choice on this space

@olivierlambert that is a discrepancy between what was planned ( a vm delta backup) and what we can do with the data available ( a full ) . In this case, it's only one disk that fell back to full

We have to improve how to show the information with mixed state

@yaroz it loosk like there is an issue with some error not stopping the job as expected, I am currently working on this

In the meantime , you can restart XO , it will forcefully close all running jobs

@olivierlambert because of time constraints and some decision to take on which tag do we use if the VM had changed. We pushed back these deceision until mirror were more widely used .

( easiest way would be to use always the last tags. )

To be fair, If possible I would prefer to wait for XO6 , the backup form in XO5, is quite complex to modify

@Pilow This one should be doable, I am adding it to our backlog

@Pilow what would need to change a lot of things. We are starting a project to rewrite the ACL, and I think it's a better way to handle it. But it will take time before releasing it.