@florent I disabled CBT on the vms and re-ran a delta backup. I noticed the following. While watching the backup task when it shows [XO] Exporting it will not show the percentage and completion. Watching backup task a vm will show not using NBD at first but using XO and then fail. The backup log will then show vm fell back to full backup and the task will then show that it is using NBD. [image: 1776658910502-screenshot_20260420_002103.png] [image: 1776659182806-screenshot_20260420_002557-resized.png] [image: 1776659254182-screenshot_20260420_002717.png] [image: 1776659855936-screenshot_20260420_003717.png] Also with out CBT GC is not constantly spamming once a vm has finished exporting and started health check. It appears to actually be running and able to coalesce as they are no longer showing in the dashboard / health... delta job with CBT enabled - 2026-04-20T00_43_48.487Z - backup NG.txt CBT disabled delta job. two vms fell back to full - 2026-04-20T03_19_02.894Z - backup NG.txt Next delta job with CBT disabled 1 vm fell back to full - 2026-04-20T04_19_10.531Z - backup NG.txt [image: 1776658716005-screenshot_20260420_001804-resized.png] [image: 1776661420315-screenshot_20260420_010236-resized.png]

@olivierlambert +1 For creating vApps GUI in XO Reason: I recently had this configuration: VM1 - Delay 90 Seconds VM2 - Delay 100 Seconds VM3 - Delay 0 Seconds The VM3 instead of starting first, always starts last without fail. One difference I noticed is that VM3 is UEFI vs VM1 & 2 being in BIOS mode. I read elsewhere in the forum that vApps is the only reliable way to have an order. Maybe if we can somehow ensure that delay works, vApps will become less significant ?

@Pilow I did check this and it definitely completes within the hour. I am testing a lesser value for CR retention to see if this resolves it.

@gregbinsd let us know. If you do use my script. It pulls nodejs from NodeSource so it may not install the latest 24.15.0 tls. If you specific 24.15.0 it will install that version. If you need to change node version with my script use the rebuild option.

@abudef I don't know. I forwarded the question.

@MajorP93 I am not sure of which branch. can you switch to https://github.com/vatesfr/xen-orchestra/pull/9725 then when running this branch : wait for the memory to fill find the process running xo ( dist/cli.mjs ) send signal : kill -SIGUSR2 a file is created in `/tmp/xo-server-${process.pid}-${Date.now()}.heapsnapshot` Note that these exports can contain sensitive data. This will freeze you xo from a few seconds to 2 minutes, and the memory consumption after will be higher after, but this will be very usefull to identify exactly what is leaking The file will be a few hundred MB fbeauchamp opened this pull request in vatesfr/xen-orchestra open Fix(xo-server): TLSSocket memory leak — stoppable + http-server-plus incompatibility #9725

@ataxyanetwork I managed to install XOA (Current version: 6.2.2 - XOA build: 20251219) and did some more testing. I am experiencing the same issue when trying to restore from an existing backup. When I create a new backup job, I can perform a filelevel restore without any problems. However, when I rerun the job, I am no longer able to restore from the most recent backup. It only works with the initial backup. Can you also reproduce this ?

@Bytevenidos That's an interesting way of doing this, I'll have to remember it. I think the Fuel Ignition tool has a vhd output, it also produces both ignition and combustion parts for you. Worked pretty good on one test machine, but I need to go deeper into some of the other choices you can type in.

Hello @MathieuRA , @florent Moving the discussion to this thread as it seems to be tackling the same issue: https://xcp-ng.org/forum/topic/11892/xoa-memory-usage/28?_=1776334896974 I reported my findings so far over there Best regards

Thank you so much for your feedback, @Vagrantin !

@denis.grilli The problem is not the performance of the scan ... the problem is, that this storage device only consists of block devices (disks) that should go into standby mode when not used ... but I think I've found a code line that checks if other-config for an SR contains auto-scan: false... I think ...

@yannsionneau Thanks for the update! We are eagerly awaiting your findings! Thanks for looking into it.

@Pilow Thanks for the heads-up, you should be able to add back concurrency as it was before and get similar performance to before the refactoring.

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?

@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?