Exactly what @nick-lloyd said, it is important to backup XO configuration AND the pool metadata as well to be able to recovery completely.

@ph7 thanks guys!

As an update here, rebooting did resolve the issue, I thought I did so shortly after I did the restore but maybe I forgot to do so. Anyway, rebooted yesterday and the backups ran last night just as they should.

Perfect, thank you

@norrisson I don't believe so. I think I just built a new VM to replace it.

@flakpyro said in File restore error on LVMs: @john-c Do you know what would cause them to change? I am testing a restore from last nights backup so i assume the UUIDs have not changed. I could do a full restore from last nights backup however and compare to be sure. Do the restore then compare to check, to see whether they have changed. If you have done any of the following or if XOA has done any of the following when performing the requested functions, it would cause the UUID for LVMs to change:- Create a new LVM Edit Metadata Directly Delete and recreate Change Filesystem UUID Change the member disk's location address - virtual bus connecting virtual disk Also if the actions in XOA or XCP-ng affect the member disk's address visible inside of the VM then this would affect the metadata. @florent Your employer did that new Debian 12 based XOA since 2021 are the packages for lvm2 and any relevant NodeJS NPM ones included in the appliance?

@olivierlambert Thanks. I will do that. I did bump the memory up to 12GiB and the backup ran successfully but I will pursue a ticket with the 3rd party script maker as well. Thank you for your time!

@codenin Is the NAS something local or are you hosting a NAS in Azure? I guess I just got a bit confused by the mention of Azure here. Usually, with cloud providers, you want to use their services more than just directly hosting something there. So for file storage, either S3 compatible blob storage, or using one of their file share services that exposes SMB or NFS.

Your backup is a stream, doing backupressure (or not). As explained in the linked topic, it depends on dozens of different parameters. You might try to use NBD with 4 concurrent download, that might be better though, because I'm betting your bottleneck is likely XAPI export speed.

They are able, but not at a great speed. It doesn't matter how many cores, it's likely heavily single threaded and relying on how fast you can do many efficient instructions per cycle. That's why you should switch to CR.

Ping @florent

Depending on the size of your backup repo you can copy the whole disk repo to tape with tar. So you have a desaster-backup. You can also span mutiple tapes with tar. https://www.gnu.org/software/tar/manual/html_section/Using-Multiple-Tapes.html

You shouldn't run anything other than the last commit as possible (which is de934ec609b1bfb48cd598de8b096a6b4cf1f963 now).

At a certain point, I don't know when because we are talking about a home lab here. I could attach the USB HDD same as a virtual HDD and I could put exclusions on it

Question/suggestion to @julien-f and @florent

Hi, See https://github.com/vatesfr/xen-orchestra/issues/7569 ep1p created this issue in vatesfr/xen-orchestra closed Backup of metadata is missing settings options for reporting failures. #7569

@Danp Yup. I did miss it... and you were right. Thanks!