Question for @julien-f and/or @florent

A bit after this I started having trouble again. I scrubbed my delta backup sets, switched to using SMB to access the same share and so far I'm a week in with no trouble at all. Remains to be seen if the strange failures will crop up again but so far I think this is the longest I've gone with the delta backups not having some random failure. Usually, it was a backup getting stuck in Started status for a day or two then switching to Interrupted because I'd reboot the XO VM to unstick it, then one of the VM backups will fail because a VDI is attached to DOM0. I know theoretically NFS is better than SMB but for now the one that breaks least often is the better option. Of course, maybe my issue had nothing to do with NFS but for now it's felt like SMB is more reliable.

@olivierlambert nope not at all. i have a feeling that it's not the disks but more like the overhead on cpu of that boxes. V3 is more lightweight.

@cairoti said in Questions about backup features: In Delta Backup and Continuos Replication (CR), if the “Force full backup” option is selected in Schedule, will the results be identical to those of Simple Backup and Disaster Recovery (DR)? In Continuos Replication (CR), although the first backup is full and the rest are incremental backups of the Delta type, why when deleting the first backup can I later restore other backups without problems? No, that's why we are changing the names to avoid confusion. They are very different things, with only 2 families: full vs incremental. Full will always generate XVAs, while incremental work differently. See: [image: Schema-new-wording-backup-2.png] Because we are smart and when you remove it via XO UI, it will automatically regenerate a full from the penultimate backup.

The problem still existed on latest as of earlier today. I removed the VM from the original (Smart Mode) backup job and cleaned up any VDI's and detached backups. As a test I created a separate backup of the VM in question pointing to the same target, this backup was successful. Hopefully I've worked around the issue, I will try adding the VM back into a Smart Mode job in the coming days.

@Danp Hi, I just updated the commit via a git pull and a yarn build. Here is the commit version: 'Xen Orchestra, commit da84a'. I tried to restore the VMs again, but I still encounter the same error. Expected values to be strictly equal: + actual - expected + '8d1c3759-e958-465f-a018-87afc098642f' - 'fed97090-e59f-43e4-adad-3bb8ba8716f2' Knowing that I have the VHDs in my possession, is it possible to restore the full .VHD with the Deltas? I tried importing the full VHD via the web browser import, but after 20 minutes, the loading gets canceled. Is it possible to do this via the CLI? If you have any documentation on this, I'd appreciate it Thank you very much. Itayal

Hello all! It should be fixed https://github.com/vatesfr/xen-orchestra/commit/72592a54d2225d5368a3410e4b3c19039f8e5df1 0 b-Nollet committed to vatesfr/xen-orchestra fix(backups): correctly update allowed_operations - temporary fix (#7924) Fixes https://xcp-ng.org/forum/post/81327 `allowed_operations` are currently not updated correctly when `blocked_operations` are modified, which causes backup jobs to remove `migrate_send` and `pool_migrate` from VM's `allowed_operations`. This commit fixes that, until `allowed_operations` updates correctly again.

@olivierlambert Yes, once CBT with Snapshot purge is production ready that will totally solve our problem! Perhaps its better to just wait for that. I wondered if they were doing something like a partial restore of the metadata as well.

@olivierlambert Thank your for poiting this out! Very much apreciated!

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.