Need FeedBack: New version of the File level restore

florent

we did a lot of ground work on the file restore front , and have plan to continue working on it.

What is testable and should work :

restore from partition of types :
- ext2 / ext3 / ext4
- XFS
- Btrfs
- FAT / VFAT / exFAT (in-kernel since 5.7)
- NTFS3 (new in-kernel driver, since 5.15 — parallel to ntfs-3g)
- f2fs
- ISO 9660 / UDF (optical media)
- squashfs / erofs (read-only images)
restore from LVM as long as there is only one VDI involved
handle disk without partition table, with GTP, with MBR

Note that, by design, the file restore is slow : each time the xoa want to read 4KB of data or even 1B we have to load a full backup block (2MB) decrypt, and inflate it ,extract the 4KB , ... . Expect 1/10 to 1/30 of your remote performance

But at least it should not crash anymore, with zip or tar restore. The worse we tested is a windows folder ( 26GB , 10 of thousands of files)

For now the fixes are in https://github.com/vatesfr/xen-orchestra/pull/9776 ( branch fix_flr ) and are expected to reach master during next week

fbeauchamp opened this pull request in vatesfr/xen-orchestra

open fix(backups): file level restore : omnibus fixes #9776

Andrew

@florent LVM restore still failed for me (fix_flr commit b7230). Trying file restore from Ubuntu 22 VM (on S3 delta backup). Single VDI, 3 partitions (bios, uefi boot, LVM root). Accessing the LVM root.

Jun  5 15:26:28 xo2 kernel: [16230.122916] loop5: detected capacity change from 0 to 21474836480
Jun  5 15:26:35 xo2 xo-server[4046]: 2026-06-05T19:26:35.793Z xo:api WARN admin | backupNg.listFiles(...) [146ms] =!> Error: Command failed: mount --options=loop,ro,sizelimit=20397948928,offset=1075838976 --source=/tmp/ouit10u6k3f/vhd0 --target=/tmp/d4l0v4n01h
Jun  5 15:26:35 xo2 xo-server[4046]: mount: /tmp/d4l0v4n01h: unknown filesystem type 'LVM2_member'.