Offline
On tomorrow 's release we will:
following this we will add core xo metrics to the openmetrics ( prometheus) export to allow users and support to dig through real world data when needed
Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects
better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this
In any case, both are on our backlog
@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:
@andrewreid Yes, I can't wait to share it with everybody.
@AlexD2006 thanks for signaling this, we just merged a fix, that fix it on our labs
can you test it on your side ?
https://github.com/vatesfr/xen-orchestra/pull/9202
@AlexD2006 this looks like the right issue, we will look into it immediately ( yesterday was a public holiday in France)
@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
@ducatijosh did you do a yarn build ?
@bvivi57 xo do check license if you have xostor installed, since it need some magic to work at a lot of steps ( like the rolling pool updates)
this is the expected behavior with a manually installed xostor ( cc @julienxovates for information )
@acebmxer not yet
(a little under the water with the release patch, but we will do it )
@DustyArmstrong for now the rest api doesn't support server side sorting ( we don't have the memory budget to do this )
it will be improved in the future
is it possible that your NFS need some specific options ( like nfs version ? )
I didnt setup ssh on work XOA i just set the password but need to reboot it for it to work. The tunnel is still open if you dont mind doing it otherwise I will need to reboot xoa to get in myself.
I can do it on monday
@acebmxer
If you are ok, you can do a heap memory export ( not that you will probably have to restart the xoa after to free the memory)
If you can do it, and we will collect the memory file on monday ( or when you are ready) , and see if this is a new cause or the return of an old one
@poddingue there is a cache system that keep the disk open a few minutes, we will rework it in the near future, it should improve the situation on these errors ( at the cost of being a little slower )
ping @julienxovates I think we can change thie behavior ( accepting a xo-server start even if a zombie process is still running)
