@poddingue said:

While you experiment, do the failing VMs have something in common? The same source SR, for example, or a mirror target keeping a different retention than the source.

There are two backup jobs that are failing. One from Ark (local) to Synology, and one from Ark to S3. It seems to be the same VMs failing each night, but interestingly, there are some that fail to Synology but succeed to S3 and vice-versa. There are 9 VMs that fail for both. They do not all share the same SR. The backups on Ark are coming from several delta jobs that run daily, weekly, and monthly. Retention are different for all those.

FWIW it seems to be the same VMs and same VDIs each day. I'm doing some additional experimentation and testing.

@acebmxer Of course, sorry. We have XO from sources, currently commit 0be90. I'm not aware of any beta updates? I'm attaching the latest log for one of the jobs.
2026-10-27T06_00_00.022Z - backup NG.json.txt

@poddingue Yes, thanks, I reviewed that post.

I've just removed ALL the backups for one VM and created a new Full backup; When I run the mirror job it again says Missing vdi f04fb96a-5923-4c75-bb42-6c916497885c which is a base for a delta.

Our mirror backup jobs continue to fail about 50% of the VMs with this Missing vdi which is a base for a delta error. I have deleted the data from the remote(s) and the problem comes right back. I'm not sure what is causing it. The backups on the source remote pass health checks.

@kruess That doesn't make sense. It should say the tools are NOT installed.

When importing a machine from VMware, Xen Orchestra says "Guest Tools status: The tools are installed." It says this for VMs where VMware tools are not installed.. and furthermore why does it matter when they need to be removed anyway? I'm not understanding what this message is for.

The documentation for the backup health check states:
An example in bash is shown in @xen-orchestra/backups/docs/healthcheck example/wait30seconds.sh
I'm not clear on where this is actually located nor have I been able to find it.

@olivierlambert Thanks yet again.

Pardon me if this has been asked elsewhere but.. The documentation states:

In Xen Orchestra, Metadata backup is divided into two different options:

Pool metadata backup
XO configuration backup

What is the difference between these?

@florent increasing the timeout value was the solution. Thank you.

@florent Thank you, I will try this.

@DustinB XOCE commit 9b6d1, XCP-ng 8.3.0, backup remote is NFS on Synlology.

I started a restore yesterday, and it said it was going to take some hours so I left it running.. When I came back to XO today, there are no pool tasks listed for importing, there is a API call: backupNg.importVmBackup task that is "started," and under Restore shows as started as well but there is no traffic between the system and the remote. It seems this backup will never complete, and I can't cancel it either. The raw data for the restore shows "transfer" is "pending."

Additional info:

uuid ( RO) : 127a8a7b-e277-27dc-802f-7f779676e18e
name-label ( RO): Async.VBD.eject
name-description ( RO):
subtask_of ( RO): <not in database>
subtasks ( RO):
resident-on ( RO): 74e89397-c334-43f5-8322-5331c31ae368
status ( RO): pending
progress ( RO): 0.000
type ( RO): <none/>
result ( RO):
created ( RO): 20251106T19:44:14Z
finished ( RO): 19700101T00:00:00Z
error_info ( RO):
allowed_operations ( RO):
current_operations ( RO):
other-config (MRW): debug_info:cancel_points_seen: 1

@acebmxer Will try at the next opportunity.

@olivierlambert Yes it is. I currently have one eject task at 0% for 19 hours...

I'm moving some VMs from ESXi to XCP-ng, and it seems that whenever I eject the tools iso, the Async.VBD.eject task never goes away unless I restart the toolstack. How can I get these tasks to complete?

@DustinB Still there in commit d77d6. The deselected CPU disappears from the graph but reappears when it refreshes.