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

@McHenry I dont think more than 3 snapshots triggers an error, just tested on one VM [image: 1776240682471-a150619d-1010-4efc-80ec-9dc4bcc730b0-image.jpeg] it is not recommended for "in production" VMs, but for a CR destination, it's OK (as you would need to start a copy anyway) your problem, failing CR jobs is probably due to garbage collection not finishing in the one hour timeframe when chain is long.

Q1: Can I disable the auto-scan completely for a single SR? That particular SR only contains block devices (disks) that I pass through directly to VMs. Those disks are > 2 TB and I'd love to put in standby when they are not in use. One of them is only used as a backup target within that VM and I've created a service that runs hdparm -S 150 /dev/sdc in Dom0. Putting the disk in standby works, but the rescan wakes up that disk. Q2: If I can't disable rescans ofr individual SRs. Can I set the rescan interval to 86400 (once per day) on the whole host. Is there any negative effect in a homelab setting? Q3: Does a manual "Rescan" on the SR trigger the same cleanup jobs (e.g. coalesce of snapshots), that the periodic scan does?

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

@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