Hello, More info on this. I think this error is related with the recent "Distribute replication accross the storage repositories" option that I turned on. Before this option existed, I was splitting the VMs into groups, with tags, and using several jobs with "smart mode" to send each group to a specific SR on the destination replication pool. With this new option I didn't have to do this anymore, it would simplify my replication job. That said, I still have a group that I want to replicate to a local host disk. This group doesn't fail with "checkBaseVdis() failed" but I do get duplicated VMs on the destination pool, even though the job's schedule is set to only 1 replications retention. Is XO failing to delete the previous VM replication ? [image: 1784273211284-fd5eacaa-1243-4835-bdcd-99ed2b8c9e96-image.jpeg] (The same VM duplicated on the replicated pool even though replication retention is set to 1) [image: 1784273391692-691d71ce-edf2-4a7d-8608-7ab46c08a2ce-image.jpeg] (Job / schedule retention settings). ...So I have to prune the duplicated VMs to make sure I don't run out of space on the target pool repository. I think I'll set up a new job with a single test VM so I can run it several times and try to gather more info.

@ph7 said: They run once a day @ 03:04 before the normal backup that starts @ 03:10 and they have all run OK since July 8, the failed one reported 8 days ago ( post ~85 ) Hi, just to be sure, are you saying it is working ok apart one task 8 days ago?

@simonp , thank you very much and all of your team ! ! ! Keep up the outstanding work. Regards, Marc

@pierrebrunet Hello! I've checked B2 logs and found some errors like you had foreseen. I had a look and this kind of 500 INTERNAL ERROR several times on other jobs that seem ok. How many retries does XO attempt to send the part when this happens? I'll do another run that includes only a few large VMs. BTW, is there a way to interrupt the job withou restarting XO ? REST.PUT.PART Weekly/xo-vm-backups/60b4d2a7-3f91-f0f9-b0a0-f834df3ff9ee/20260705T070618Z.xva "PUT /zzzzzkly/xo-vm-backups/60b4d2a7-3f91-f0f9-b0a0-f834df3ff9ee/20260705T070618Z.xva?partNumber=3954&uploadId=4_ze092693d1b65962e9fe6051b_f25969add7e42e384_d20260713_m140016_c003_v0312040_t0013_u01783951216751&x-id=UploadPart HTTP/1.1" 500 INTERNAL_ERROR 145 - 3762 3762 "-" "aws-sdk-js/3.1065.0 ua/2.1 os/linux#5.15.0-185-generic lang/js md/nodejs#24.18.0 api/s3#3.1065.0 m/N,a,c,E,e xen-orchestra-fs-4.9.2" - - - TLS_AES_256_GCM_SHA384 AuthHeader s3.eu-central-003.backblazeb2.com TLSv1.3 - -

Hi @acebmxer, thanks for reporting, we identified this bug internally already, we're going to fix it once root cause is found.