@Andrew
I'm not sure I understand what you meant.
Full VM restore is working, the issue is with file-level restore. So restoring a full 200GB VM just to retrieve 2 or 3 files isn't really a viable solution.

@peo Thanks for the info!
I also tested it with XOA and got the same result.
However, when deploying the same VM without LVM, file restore worked perfectly with both XO and XOA.
It definitely seems related to the GitHub issue.

In the meantime, I've switched to a commercial backup solution until it's resolved.

@olivierlambert,

Why would this issue be related to my NFS share? I can access the share without any problems, read and write operations work fine. Other NFS shares with multiple applications running are also functioning normally.

I checked the XO logs and found the following:

xo-server[679]: 2025-04-29T21:45:58.276Z xo:api WARN  | backupNg.listFiles(...) [114ms] =!> Error: Command failed: vgchange -ay vg_iredmail
xo-server[679]: File descriptor 22 (/var/lib/xo-server/data/leveldb/LOG) leaked on vgchange invocation. Parent PID 679: node
xo-server[679]: File descriptor 24 (/var/lib/xo-server/data/leveldb/LOCK) leaked on vgchange invocation. Parent PID 679: node
xo-server[679]: File descriptor 25 (/dev/fuse) leaked on vgchange invocation. Parent PID 679: node
xo-server[679]: File descriptor 26 (/var/lib/xo-server/data/leveldb/MANIFEST-000103) leaked on vgchange invocation. Parent PID 679: node
xo-server[679]: File descriptor 31 (/dev/fuse) leaked on vgchange invocation. Parent PID 679: node
xo-server[679]: File descriptor 34 (/var/lib/xo-server/data/leveldb/000356.log) leaked on vgchange invocation. Parent PID 679: node
xo-server[679]:   WARNING: Couldn't find device with uuid oWTE8A-LNny-Ifsc-Jmtp-lTkB-dSjt-2AqhwY.
xo-server[679]:   WARNING: VG vg_iredmail is missing PV oWTE8A-LNny-Ifsc-Jmtp-lTkB-dSjt-2AqhwY (last written to /dev/xvda4).
xo-server[679]:   Refusing activation of partial LV vg_iredmail/lv_root.  Use '--activationmode partial' to override.

To me, this looks more like an issue with file restore than the NFS itself.

It seems similar to what's reported here:
https://github.com/vatesfr/xen-orchestra/issues/7029

andrew64k created this issue in vatesfr/xen-orchestra

open File level restoration not working on LVM partition #7029

I just deployed a new NFS share for testing.
The share is mounted on both XO and the newly deployed XOA.
I backed up a VM that I can see the files in using XO.
I faced the same issue with both XOA and XO, I can’t see the files.
I backed up the same VM using XOA and tried to restore the files, same issue.

@olivierlambert
Just tried on XOA, I can't mount the NFS share on it. I get :

Test remote
Unsupported state or unable to authenticate data

@olivierlambert

Ok, now it's clear!

@AtaxyaNetwork
Already installed :

lvm2 is already the newest version (2.03.16-2).

@olivierlambert
Don’t have XOA on hand.
Besides that, all backup jobs are already set up on XO…
Is this a common issue? Is there something I can do to fix it?
I was thinking of doing the backup on an unencrypted NFS share. Would that fix it?

@olivierlambert
My bad, it's on XO from the sources.
I didn’t take the filesystem into account.
After checking my backups, I can see files on EXT filesystems but not on LVM filesystems.

Hi o/

I'm facing an issue with file restoration.

On some VMs, I can see the file and restore them :

On other VMs, I can't :

Both VMs are backed up in the same way, using the same job.
Backups are done on an NFS share, and remote backups are encrypted on XO.

Any idea why this is happening?