Need FeedBack: New version of the File level restore

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'.

ph7

@florent
fix_flr commit b7230
Restored files from debian 12 on local ext
and from Linux Mint 22.3 on NFS
both with tgz and zip

ravenet

@florent

Any plans for ReFS?

olivierlambert

There's no open source driver for ReFS, so…

florent

@ravenet not directly, it's not mountable into linux

But if ( and this is a big if) we are able to make FLR more resilent, I have some next step that would expose the disks so you can mount it directly in your preferred OS or XCP , probably through webdav

florent

@Andrew thank

I pushed some fixes , can you retry the VM . With this config in the toml ? if it fails if will gives us more logs in journalctl

[logs]
# Display all logs matching this filter, regardless of their level
filter = 'xo:backups:RemoteAdapter'

Andrew

@florent Ubuntu LVM file restore is working! (commit 38931)

Now for another important issue I noticed with file restore (not directly LVM).

Symbolic links don't show up. They should be restorable alone, but more importantly you need to be able to see and follow them for directories.

For example. In Ubuntu, /bin is a link to /usr/bin. It is important to be able to click on /bin as a link to /usr/bin so files can be found in the backup. Another example is /vmlinuz that is a link to boot/vmlinuz-5.10.0-44-amd64. At worst the file restore should show a link (and it's destination), even if I can't restore the link. This is not just a LVM issue.

florent

@Andrew good news : the lvm id/name collision is the root cause of a lot of issues of the the file restore.

I think restoring the symbolic links will be hard to secure ( a symbolic link can point anywhere in the os and the disk are mounted in the xoa as root) and quite tricky to ensure we are not bombing ourself

I think we can add them to the zip/tar as (brokenà symbolic link, but we need to look into the impact on the client side file browser

Andrew

@florent As a note, I'm using Debian as the base OS for XO. Other OS, like Ubuntu may have other name conflicts...

As for links, the dropdown box should show the link and it's destination). As a link, I don't think you need to "follow" it when selected (like a directory would), it's just a file. I did not check other non-standard files (like devices).

If I select a directory to restore then it would be good if the links are included. Both tar and zip do support links, so they should be restorable.

florent

@Andrew working on it with @julienxovates

at least including them by default , without following them, in the archive seems doable . The change on the XO5 UI may be trickier, and we are not far to rewrite it for XO6