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
@olivluca skip ssl check in the import form
@olivluca even with the self signed toggled on ?
@olivluca it looks like a network issue , can XO access the vsphere/esxi through NBD ?
@blueh2o the restore should have timeout . Is it possible that it run more than 24h ?
you should restart xo-server, increase the timeout and retry https://docs.xcp-ng.org/management/manage-locally/api/#_24h-task-timeout
@guillemrebull in your xo logs, you should have a line like nbdkit logs of ${diskPath} are in ${tmpDir}
could you copy here the file in tmpDir ( something like /tmp/xo-serverYYYY/stderr ) ?
@MajorP93 ineresting
so the same file set to restore was locking the xoa in tar but not in tar gz
do you know how many files and their size in this folder ?
@jsajous26 AFAIK this is not possible to call a script inside the VM through the guest tools. Maybe on veeam side there are other way to do this ( throug ssh / powershell) ?
@nikade any logs can help fix the issue, but don't make too much effort on getting them back. We will meet the issue again one day if we do not have fixed it
(importing data is fairly honest : any missing bits and the xapi, the file system or both explodes immediatly)
@jsajous26 sorry I misread. I don't know how ti setup this while using veeam
