On tomorrow 's release we will:

• reduce the polling for the patches list
• add more debug to know exactly what request go through the xo6 api (rest api)

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

@Forza

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:

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

@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

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(backups): getOldEntries must accept entries without id or timestamp #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

fbeauchamp opened this pull request in vatesfr/xen-orchestra

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

@Pilow said:

(file:///usr/local/lib/node_modules/@x

fix is here https://github.com/vatesfr/xen-orchestra/pull/9667

fbeauchamp opened this pull request in vatesfr/xen-orchestra

open fix(backups): schedule reference is missing #9667

@joeymorin said:

I observed similar behaviour.

Two pools. Pool A composed of two hosts. Pool B is single-host. B runs a VM with XO from source. Two VMs on host A1 (on local SR), one VM on host B1 A2 (on local SR).

Host A2 has a second local SR (separate physical disc) used as the target for a CR job.

CR job would back up all four VMs to the second local SR on host A2.

The behaviour observed was that, although the VM on B would be backed up (as expected) as a single VM with multiple snapshots (up to the 'replication retention'), the three other VMs on the same pool as the target SR would see a new full VM created for each run of the CR job. That rather quickly filled up the target SR.

I noticed the situation was corrected by a commit on or about the same date reported by @ph7.

Incidentally, whatever broke this, and subsequently corrected it, appears to have corrected another issue I reported here. I never got a satisfactory answer regarding that question. Questions were raised about the stability of my test environment, even though I could easily reproduce it with a completely fresh install.

Thanks for the work!

edit: Correction B1 A2

sometimes it's hard to find a n complete explanation without connecting to the hosts and xo, and going through a lot of logs , which is out of the scope of community support

I am glad the continuous improvement of the code base fixed the issue . We will release today a new patch, because migrating from 6.2.2 to 6.3 for a full replication ( source user that updated to the intermediate version are not affected )

@Pilow open a dedicated topic on this . I will ping the relevant team there
is it iscsi + CBT ?

@Andrew the NBD warning is probably doable.
the other solution is not : NBD is mandaotry to use CBT ( the fallback with export can't work without a real snapshot )

@flakpyro yes this one : https://github.com/vatesfr/xen-orchestra/pull/9635

fixed this morning in our work branch, and merged this after noon . We also explicited some edge cases here : https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/backups/docs/VM backups/incrementalReplication.md (that will probably be ported to the main doc shortly )

thank you for your input

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups): improve incremental replication #9635

yes, the last changes are released in latest ( 6.3) tomorrow if everything proceed as intended

mostly : https://github.com/vatesfr/xen-orchestra/pull/9622
https://github.com/vatesfr/xen-orchestra/pull/9557

and this one was in 6.2 :
https://github.com/vatesfr/xen-orchestra/commit/e36e1012e20c9678efa15148179941cb284c39a6

that's nice to hear

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(xo-server): use index for getAllUnhealthyVdiChainsLength #9622

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(backups): better handling of generator cleanup #9557

0 fbeauchamp committed to vatesfr/xen-orchestra

fix(xo-web): reducing polling for patches and license

@flakpyro you probaby had multiple job/schedule on the same schedule

I reworked the code and pushed an update and added a doc with the edge cases : https://github.com/vatesfr/xen-orchestra/pull/9635/changes#diff-ef545af2ad06f2759c1a3787f266108b3b2cbc203bc8071bbd847278f3e6a5f0 (will be on doc xo when merged )

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups): improve incremental replication #9635

@flakpyro could you test this branch ?
https://github.com/vatesfr/xen-orchestra/pull/9635/commits

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups): improve incremental replication #9635

@JSylvia007 Error: stream has ended with not enough data (actual: 397, expected: 2097152) is the root cause, can you post the json here ?

remove the snapshot on the source to start a new backup chain .

I am on it , thanks for all the informations