Offline
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
@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation
@archw could you share the full json report ? ( the download button at the top of the backup log )
@Pilow We pushed a lot of memory fixes to master, would it be possible to test it ?
@henri9813 the warm mode is more manual by XO, and it can replicate from almost any version to any version, or any CPU to any CPU
the direct migration has some precondition : always migrate to te same or superior version. Live migration also add some condition on the CPU brand and generation
@dave.opc that's it
keep us updated on this
@acebmxer yes after the first migration, XO knwo that the migration is incomplete and that you may want to finish it later. But if you start this VM direvtly , it will write some data, thus it won't be in sync anymore with the Vmware snapshot. Then XO won't be able to resume
You can start a copy of the VM ( XO will handle it for you ) and delete the copy when you're done
My advice is to migrate this VM to the right SR and then do the resume. But keep in mind that the V2V tool is intended to target only one SR, so migrate all they disk to the same SR, and select the right one when resuming the V2V. You can change the network after
@dave.opc it should work . Add [NoBak] to one disk, transfer it, then remove the [NoBak] on the 2nd , restart the transfer => the first one will only transfer a delta , while the second disk will be transfered as full . If you put [NBak] on the first one for the second transfer, it will be handled as a disk deleted and will remove it on the replica
Note you will have the same issue if ( when ) you'll need to do a full backup later on, for example if there are any replication issue, or if you want to ensure your base copy is not corrupted later on
hi @planedrop
could you send us the full json of the backup log ? is the disk still attached to dom0 ( in dashboard => health )
(the task will disappear after 24 hours at worste)
@john.c yes for sure, and maybe we will be able to set the chunk size on a future date ( especially since we did some of the ground work for vhd / qcow2)
