@simonp patched tonight, a job who took 3 hours yesterday took only 1 tonight. so, big improvment ! need to re up concurrency to 2 or 4 on some jobs to see if I can squeeze more time on the backup window

@florent @mathieura XOA is giving alart about Memory running low.... I have not rebooted xoa or aything since @florent applied patchs to xoa. Support tunnel still open. [image: 1776189947547-screenshot-2026-04-14-140230.png]

I updated to branch "mra-fix-rest-memory-leak". I will look at backup job results tomorrow and report back.

Thank you for your feedback @kratos !

it's only possible to change management interface. [image: 1776174536719-d5cbdf34-9bd7-42fd-9866-6f7474550be7-image.jpeg] nothing can be done with other NICs. weird, what is this? [image: 1776174634577-5630d95a-79e5-421f-811c-1da5746b8812-image.jpeg]

@archw Could the results you are observing be due to the fact that some of the files weren't modified in the specific delta backup that you selected as your restore point? For example: In another subdirectory there are supposed to be 7 files but in the selection window there are only two. When were these 5 "missing" files last modified?

@Pilow Agree.... have to be sure that garbage collection is completed or it'll never catch up if backups continue to be run without the coalesce completing.

@Aleksander There are plenty of examples on this forum. We have used Nvidia T4, it works very well.

@anthoinebThe problem still persists; when can we expect it to be resolved?

perhaps "in the context of a proceeding RPU, do not start halted VMs" ? or "boot only halted VMs that have HA enabled" ? but I can imagine corner cases where this is not wanted. some chicken & egg problem.

@Mark-C this is not forgotten, but file level restore has been under priorised, so it didn't get much work it is now quite high on our backlog , so expect good news in the next months

@tsukraw No worries! Just glad that we can all help each other out!

@flakpyro that's a good news ( but at least another user saw this) we are currently testing the branch ensuring that at least the fix don't create other issues

Hi @olivierlambert and @pilow Thank you for your answers, it helps a lot, Regards, Olivier

@TechGrips Sorry, there is no quick test to be sure the VM is not corrupted. The usual way would be to make a healthcheck. We cannot be sure everything is ok as it concerns multiple tar linked to each other. If it keeps warning you on the same backups, it may be due to a faulty parent. You would need for this to create a new chain of snapshot

@cobordism said: yum update --disablerepo=* --enablerepo=xcp-ng-base,xcp-ng-updates It's currently in testing and will move to updates if everything (not only nut) is ok: yum install --disablerepo=* \ --enablerepo=xcp-ng-base,xcp-ng-updates,xcp-ng-testing nut

new mail received from Laurent Nguyen today Bonjour, Face à la hausse des tarifs VMware, nous vous invitons à remplir un questionnaire pour mieux comprendre vos attentes et améliorer nos services. https://www.surveymonkey.com/r/288HCLL Merci d’avance pour votre temps. Et si n’est pas encore fait, n’oubliez pas de vous inscrire au Veeam Technical Cloud Club qui aura lieu le Jeudi 16 Avril 2026 : https://go.veeam.com/webinar-technical-cloud-club-france Go give some love to XCP-NG + VEEAM collaboration in the survey !

@omatsei said: @omatsei I figured out the problem. There appears to be a bug in XO that requires you to check "Check Certificate" and/or "Start TLS", save the configuration, then uncheck them, then save again. Then it should work. The bug is that they're unchecked by default, but apparently they're enabled in the background. Thanks for that, I was stump on this one trying to reconfigure a new instance. This is defintely the case even with the latest auth-ldap (v0.10.11) plugin.