@acebmxer did you enabled NBD on the network ( in the pool view ? ) is it a network accessible by the xo ?

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

@McHenry said: Thanks. The old snapshots are being removed as the total never increases beyond 16, so when a new snapshot is added, the old one is removed. immediatly removed, yes, but then Garbage collection takes place. and perhaps with 19x16 GC to process it can't be done in one hour, and then next CR is launched, etc etc...

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

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

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

@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

@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

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 !

main.xxx (azazel.xxx) Snapshot Start: 2026-04-10 00:03 End: 2026-04-10 00:03 Local storage (137.41 GiB free - thin) - legion.xxx transfer Start: 2026-04-10 00:03 End: 2026-04-10 00:09 Duration: 6 minutes Size: 17.08 GiB Speed: 47.42 MiB/s Start: 2026-04-10 00:03 End: 2026-04-10 00:09 Duration: 6 minutes Start: 2026-04-10 00:03 End: 2026-04-10 00:09 Duration: 6 minutes Type: full

@Bastien-Nollet I'm running c1e5f btw

If you're looking for a quick way to verify those files without running a full restoration test every single time, you can usually run a checksum comparison (MD5 or SHA256) against the original data. For a more 'point and click' approach to double-check specific files or verify hashes quickly, I've used https://thetoolapp.com/utilities/file-integrity-checker/ before. It’s pretty handy for a quick integrity check if you aren't in the mood to mess around with the command line for every single backup set.

Hi @Pilow, Thanks for the report. We are aware that there are many problems with the FLR. We would like to fix them but they are not easy to fix, and we can't give an estimation date for a fix. I've linked this topic to our investigation ticket. For the moment, when FLR fails, we recommend to manually restore your files by following this documentation: https://github.com/vatesfr/xen-orchestra/blob/master/%40vates/fuse-vhd/README.md#restore-a-file-from-a-vhd-using-fuse-vhd-cli

@florent I can confirm that this fixes the issue!

@Pilow The backups kept by LTR are just regular backups with a specific tag, which doesn't change how we treat them. If you want to avoid each of your LTR backup to depend on one another, we recommend to set a full backup interval value to your backup job, which will regularly force a full backup. (even without LTR, having an infinite chain of backups can cause problem in the long term, especially if no healthchecks are made)

@MathieuRA said: Hi, regarding your backups which do not appear on the XO5 restore page, I suggest you to open a new topic Forgot to include the link to the new topic https://xcp-ng.org/forum/topic/12040/restore-only-showing-1-vm