@florent Great work, thanks for the fixes

@florent Thanks for taking a look, much appreciated!
@siemsenit Glad to help! I can't claim credit though, @marcoi pointed out the mention of NBD in the logs

@marcoi @olivierlambert OK, I think I've found the problem, and a fix... at least for the error I was seeing...

• If you create a new backup with the method Delta Backup, it will fail with the error posted previously.
• Activate the "Use NBD to transfer disk if available" switch
• Save the backup job
• Deactivate the "Use NBD to transfer disk if available" switch
• Save the backup job
• Run the backup job again

This time, journalctl doesn't log any errors, and the export task can be seen:

My guess is, that even though by default the "Use NBD to transfer disk if available" switch is shown as inactive when creating a new backup job...

...in reality NBD is switched on by default. Activating and deactivating the switch presumably creates an entry in the job that specifies NBD shouldn't be used.

It would be interesting to know if anyone else can replicate this behaviour, or if it's just something odd in my setup?

Thanks again @marcoi - I wasn't able to get a full backup to work using the Delta Backup with Force full backup option selected. However, using the Backup method was successful, so I have backups for now. I'll try to take another look at it today and do some further testing.

@marcoi Good thinking, here we go - seems OK:

I think I neglected to mention that while backups using the Delta Backup mode failed, other modes have been working:

Thanks @marcoi - I don't believe so, though I have no experience of the Network Block Device protocol. The VMs are backed up to a NFS share on a Synology NAS, so pretty low tech in comparison to what a lot of folks here will be using. Based on this page, I'm guessing NBD isn't natively supported on these devices?

This is a sample of the settings, let me know if you need any further information:

Thanks both for the help, it's much appreciated.

@olivierlambert - apologies, I'm having some difficulty in finding xo-server... the closest I can find is a mention to it in /opt/xo/xo-src/xen-orchestra/packages/xo-server/xo-server.service:

ExecStart=/usr/local/bin/xo-server

# /usr/local/bin/xo-server
bash: /usr/local/bin/xo-server: No such file or directory

However, when I check /etc/systemd/system/xo-server.service, I get something quite different:

ExecStart=/opt/xo/xo-server/dist/cli.mjs

This file does exist, but running it with -h doesn't seem to provide a useful output:

# /opt/xo/xo-server/dist/cli.mjs -h
Usage: xo-server [--safe-mode]

xo-server v5.180.1

I can run the script in place of the service, but in terms of output it only gives me the same as the journalctl -u xo-server output (see previous attachment):

# systemctl stop xo-server
# /opt/xo/xo-server/dist/cli.mjs

2025-06-30T15:00:42.871Z @xen-orchestra/xapi/disks/Xapi WARN can't connect through NBD, fallback to stream export
2025-06-30T15:00:42.892Z xo:backups:worker WARN possibly unhandled rejection {
  error: RequestAbortedError [AbortError]: Request aborted
      at BodyReadable.destroy (/opt/xo/xo-builds/xen-orchestra-202506301106/node_modules/undici/lib/api/readable.js:51:13)
      at XapiVhdStreamSource.close (file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/xapi/disks/XapiVhdStreamSource.mjs:160:22)
      at XapiStreamNbdSource.close (file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/disk-transform/dist/DiskPassthrough.mjs:34:29)
      at XapiStreamNbdSource.close (file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/xapi/disks/XapiStreamNbd.mjs:81:19)
      at #openNbdStream (file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/xapi/disks/Xapi.mjs:92:21)
      at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
      at async XapiDiskSource.openSource (file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/xapi/disks/Xapi.mjs:198:18)
      at async XapiDiskSource.init (file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/disk-transform/dist/DiskPassthrough.mjs:28:41)
      at async file:///opt/xo/xo-builds/xen-orchestra-202506301106/@xen-orchestra/backups/_incrementalVm.mjs:67:5
      at async Promise.all (index 0) {
    code: 'UND_ERR_ABORTED'
  }
}

@marcoi - I didn't see anything appear other than this:

Edited to correct screenshot

@marcoi Hi, the service restarted as part of the upgrade process, but I have done a restart of the VM running Orchestra as well, just to be on the safe side.

Please see attached log.txt for additional log information.

git log shows the expected commit:

/opt/xo/xo-builds/xen-orchestra-202506301106# git log
commit fcefaaea85651c3c0bb40bfba8199dd4e963211c (HEAD, origin/master, origin/HEAD)
Author: Pierre Brunet <pierre.demonthelie@gmail.com>
Date:   Mon Jun 30 10:43:41 2025 +0200

    feat: technical release (#8767)

@olivierlambert Sadly, it's not working for me - I've updated to the latest commit and tested a job that should take around 5 minutes; it's been stuck on "Started" for a couple of hours now.