@florent mmm. Sounds good dns_interno2 (ctx3.tosnet.it) Wasabi transfer Start: 2025-07-27 06:02 End: 2025-07-27 06:15 Duration: 13 minutes Size: 14.21 GiB Speed: 18.73 MiB/s transfer Start: 2025-07-27 06:15 End: 2025-07-27 06:16 Duration: a few seconds Size: 314 MiB Speed: 12.17 MiB/s Start: 2025-07-27 06:02 End: 2025-07-27 06:19 Duration: 16 minutes Wasabi Start: 2025-07-27 06:15 End: 2025-07-27 06:19 Duration: 3 minutes Start: 2025-07-27 06:02 End: 2025-07-27 06:19 Duration: 16 minutes dns_interno1 (ctx1.tosnet.it) Wasabi transfer Start: 2025-07-27 06:02 End: 2025-07-27 06:20 Duration: 17 minutes Size: 25.03 GiB Speed: 24.84 MiB/s transfer Start: 2025-07-27 06:20 End: 2025-07-27 06:20 Duration: a few seconds Size: 506 MiB Speed: 16.66 MiB/s Start: 2025-07-27 06:02 End: 2025-07-27 06:23 Duration: 21 minutes Wasabi Start: 2025-07-27 06:20 End: 2025-07-27 06:23 Duration: 3 minutes Start: 2025-07-27 06:02 End: 2025-07-27 06:23 Duration: 21 minutes FtpA TEST (ctx1.tosnet.it) Wasabi transfer Start: 2025-07-27 06:19 End: 2025-07-27 07:40 Duration: an hour Size: 164.59 GiB Speed: 34.67 MiB/s transfer Start: 2025-07-27 07:40 End: 2025-07-27 07:41 Duration: a few seconds Size: 804 MiB Speed: 52.72 MiB/s Start: 2025-07-27 06:19 End: 2025-07-27 07:42 Duration: an hour Wasabi Start: 2025-07-27 07:40 End: 2025-07-27 07:42 Duration: 2 minutes Start: 2025-07-27 06:19 End: 2025-07-27 07:42 Duration: an hour

@olivierlambert Hi, Yes, I have "Merge backups synchronously" enabled on the Local Backups jobs but still get the error as the Mirror Job has a lock on the VM data. Error/Message: "the writer IncrementalRemoteWriter has failed the step writer.beforeBackup() with error Lock file is already being held. It won't be used anymore in this job execution." Start: 2025-07-26 21:17 End: 2025-07-26 21:17 Duration: a few seconds Error: Lock file is already being held Thanks.

Hello, @burbilog I think theses backup doesn't come from your backup plan. Is there maybe snapshots on the VM ? 2022 is "very old" Your full backups include memory which is not "classical" in a incremental backups.

Question for @florent

Thank you @florent. I'll do that. Update: It worked.

@olivierlambert You got it, I'll do that. Thank you.

See that as a positive experience: you have learned many things

It's better to have it to get handy options like IP addresses displayed and so on.

@olivierlambert Hmm. It may just be easier to do a restore and export. I tried doing a file restore of / but I get a Cannot GET error when trying to download the tgz. I don't see anything in the UI to indicate what the problem is or if it actually created the tgz.

@icompit Thank you. It seems that the backup process fails to get the file lock on the backup directory. Have you modified anything on your remote recently? Also, could you tell me if this is happening on all of this job's runs, all of your backup runs, or if it only happened once on this specific backup job execution?

@olivierlambert I agree, ping @thomas-dkmt

Great!

@florent Great work, thanks for the fixes

@frank-s yes please the more detailed the bug report is, the easier it is to fix

Workaround found here https://xcp-ng.org/forum/post/94626 Seems like turning "Use NDB to transfer disk if available" switch ON and save backup job, then turn the switch OFF and save backup job again, will fix the issue. Thanks to @RobWhalley and have a nice day everyone.

@DwightHat I am using xoa from sources and i updated it to the latest commit which seemed to fix it for me..

hmm, I found the solution, after I read here on forum. I enable this options and save and then disable and save and now is ok. Task is running again. It is running with last commit to So the problem is with these settings which may not exist in the task created before the update. [image: 1751377404079-05b77f69-6e87-49d2-9c62-d795a13d161a-image.png]

fixed in commit fcefa

Excellent!

Hello, I am asking XO team.