@NeilGrevitt Whilst migrating my other backups to NFS, I noticed that one of the VM backups is able to perform file restores successfully.

The successful VM is Ubuntu 22.04.1 LTS, but has been upgraded multiple times and was originally a flavour of 18.x LTS somewhere along it's life.

The unsuccessful VM is Ubuntu 20.04.5 LTS that I believe was installed at this version.

The only difference I can see is the output of lvscan, which does point to an issue with LVM!

Successful VM:
:~$ sudo lvscan
:~$

Unsuccesful VM:

:~$ sudo lvscan
ACTIVE '/dev/ubuntu-vg/ubuntu-lv' [<19.00 GiB] inherit

Not sure where to go now but thought it worth reporting!

@JamfoFL No worries about bugging me! I seriously appreciate the assistance!

I'll look at it more tomorrow, but an initial check suggests that ntfs-3g is installed. I may end up raising this issue through the GitHub installer people. I also had another error relating to Yarn and Apt that got in the way of updates.

Cheers, Neil

@olivierlambert Thanks, that would be great. My XOA instance is already registered to a previous colleague. Can I just re-register myself? Which account do I use to register XOA? Thanks!!

@olivierlambert I understand. I do have an XOA install, but no subscription, which I thought excludes Delta Backups. Thanks for your help!

Yes, I have tested file restore successfully, when I was using SMB shares, but it never seemed 100% reliable and would error with larger files.

I also had issues installing the latest updates to XO, using the Updater script from Jarli01 on Github. Basically it wouldn't start the server, so I ran the updater again and it seemed to work fine, but it's bugged me since. Perhaps there is a missing or outdated dependency?

Hi,
Since moving my delta backups onto NFS, to solve my previous issue. I now see an error when testing the file restore option, the little red triangle appears!.

Looking on the server, the following error is generated:

Nov 21 15:00:58 xoce xo-server[713]: 2022-11-21T15:00:58.147Z xo:api WARN admin@admin.net | backupNg.listFiles(...) [829ms] =!> Error: Command failed: mount --options=loop,ro,norecovery,sizelimit=534720282624,offset=2149580800 --source=/tmp/njiyo1znyq/vhd0 --target=/tmp/t1f23sptbm
Nov 21 15:00:58 xoce xo-server[713]: mount: /tmp/t1f23sptbm: unknown filesystem type 'LVM2_member'.

I appear to have NFS correctly setup, the remote test option works, and the backup completed successfully.

This is using the new "multiple data blocks" option for the remote.

Any guidance would be appreciated!

Thanks all for your comments. I've managed to overcome the NFS errors listed, by using the new "multiple data blocks" setting! So for me, looks like backing up to .vhd won't work on either SMB or NFS.

I may not have NFS correctly setup, as now I get a failure during the transfer stage:

Nov 18 16:45:33 xoce-new xo-server[10801]: 2022-11-18T16:45:33.150Z xo:backups:VmBackup WARN writer step failed {
Nov 18 16:45:33 xoce-new xo-server[10801]:   error: AssertionError [ERR_ASSERTION]: footer1 !== footer2
Nov 18 16:45:33 xoce-new xo-server[10801]:       at VhdFile.readHeaderAndFooter (/opt/xen-orchestra/packages/vhd-lib/Vhd/VhdFile.js:192:7)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async VhdFile.open (/opt/xen-orchestra/packages/vhd-lib/Vhd/VhdFile.js:96:5)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async openVhd (/opt/xen-orchestra/packages/vhd-lib/openVhd.js:10:12)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async Promise.all (index 0)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async checkVhd (/opt/xen-orchestra/@xen-orchestra/backups/writers/_checkVhd.js:7:3)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async NfsHandler._outputStream (/opt/xen-orchestra/@xen-orchestra/fs/dist/abstract.js:562:9)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async NfsHandler.outputStream (/opt/xen-orchestra/@xen-orchestra/fs/dist/abstract.js:186:5)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async RemoteAdapter.outputStream (/opt/xen-orchestra/@xen-orchestra/backups/RemoteAdapter.js:682:5)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async RemoteAdapter.writeVhd (/opt/xen-orchestra/@xen-orchestra/backups/RemoteAdapter.js:677:7)
Nov 18 16:45:33 xoce-new xo-server[10801]:       at async /opt/xen-orchestra/@xen-orchestra/backups/writers/DeltaBackupWriter.js:220:11 {
Nov 18 16:45:33 xoce-new xo-server[10801]:     generatedMessage: false,
Nov 18 16:45:33 xoce-new xo-server[10801]:     code: 'ERR_ASSERTION',
Nov 18 16:45:33 xoce-new xo-server[10801]:     actual: false,
Nov 18 16:45:33 xoce-new xo-server[10801]:     expected: true,
Nov 18 16:45:33 xoce-new xo-server[10801]:     operator: '=='
Nov 18 16:45:33 xoce-new xo-server[10801]:   },

@olivierlambert I've seen the mentions of it here also. It's strange as it's been working for the last 18months without issue!

I shall try to setup NFS. One thing that prevents me doing, (although I would imagine massively unsupported), is making copies of the larger VHD files from the SMB share on a Windows machines, as you can mount them to get at the files. Restoring large amounts of files through the browser doesn't work for me. Perhaps NFS would resolve that also! Thanks

Hi,

I am running xo-server 5.105.0 and xo-web 5.106.0 on Ubuntu 20.04.5 LTS, backing up a Xenserver, which has been running without trouble for many months.

I recently updated the server from a previous version, and since then the scheduled delta backups have been being deleted from the remote during the merge process. This is almost identical to another issue here

I am using TrueNas 13.0 SMB share as the remote. I'm running the old .vhd style of backup and have no syslog configured (afaik)

Output from journalctl is:

Nov 18 08:40:53 xoce xo-server[2223]: 2022-11-18T08:40:53.324Z xo:backups:mergeWorker INFO merge in progress {
Nov 18 08:40:53 xoce xo-server[2223]:   done: 1489,
Nov 18 08:40:53 xoce xo-server[2223]:   parent: '/xo-vm-backups/5371b36f-f3d2-bb48-6525-79a9def027da/vdis/890c2c65-027d-4d9d-ae9d-8580c4c1a802/a69eba8f-2f1f-4ca4-a5ad-7629f059abd3/20221117T060008Z.vhd',
Nov 18 08:40:53 xoce xo-server[2223]:   progress: 100,
Nov 18 08:40:53 xoce xo-server[2223]:   total: 1491
Nov 18 08:40:53 xoce xo-server[2223]: }
Nov 18 08:40:58 xoce xo-server[2223]: 2022-11-18T08:40:58.189Z xo:backups:mergeWorker WARN failure handling task {
Nov 18 08:40:58 xoce xo-server[2223]:   error: [Error: EACCES: permission denied, rename '/run/xo-server/mounts/9e36d44a-9bad-4df6-8b1a-0f6181ac1bfb/xo-vm-backups/5371b36f-f3d2-bb48-6525-79a9def027da/vdis/890c2c65-027d-4d9d-ae9d-8580c4c1a802/a69eba8f-2f                                                                                                                       1f-4ca4-a5ad-7629f059abd3/20221117T060008Z.vhd' -> '/run/xo-server/mounts/9e36d44a-9bad-4df6-8b1a-0f6181ac1bfb/xo-vm-backups/5371b36f-f3d2-bb48-6525-79a9def027da/vdis/890c2c65-027d-4d9d-ae9d-8580c4c1a802/a69eba8f-2f1f-4ca4-a5ad-7629f059abd3/20221118T083                                                                                                                       549Z.vhd'] {
Nov 18 08:40:58 xoce xo-server[2223]:     errno: -13,
Nov 18 08:40:58 xoce xo-server[2223]:     code: 'EACCES',
Nov 18 08:40:58 xoce xo-server[2223]:     syscall: 'rename',
Nov 18 08:40:58 xoce xo-server[2223]:     path: '/run/xo-server/mounts/9e36d44a-9bad-4df6-8b1a-0f6181ac1bfb/xo-vm-backups/5371b36f-f3d2-bb48-6525-79a9def027da/vdis/890c2c65-027d-4d9d-ae9d-8580c4c1a802/a69eba8f-2f1f-4ca4-a5ad-7629f059abd3/20221117T060008

As part of troubleshooting, I created a new Ubuntu VM and installed XO from scratch, and updated to the latest version xo-server 5.106.1 and xo-web 5.107.0, which gives the same results.

Many thanks
Neil