@olivierlambert It's really just a "nice-to-know", since provisioning systems are often based off of the distro version. If xcp-ng uses EL9 as its "base", then I can prepare by making sure the<insert-application-here> configurations to be deployed on a new xcp-ng instance will be compatible with whatever <insert-application-here> version is used on EL9. That's all (for me).

This should probably be pinned somewhere unless I missed it, but what's the plan going forward for XCP-NG 8.3+ with respect to OS? Will XCP-NG be using AlmaLinux 9, Rocky Linux 9, CentOS Steam 9? Please tell me it won't be Debian-based...

@marcungeschikts Thanks, that's perfect!

@marcungeschikts I understand that this issue has been solved by halting a VM before taking the snapshot. Per this comment by @julien-f , "[...] but we have discussed with the XCP-ng team and they are working on improving this", is there an issue or feature request or ticket to track XCP-ng's work to improve the implementation so that halting a VM is no longer required?

@julien-f said in XO Backup [NOBAK] for full backups:

Hey everyone, [NOBAK] should work for all types of backup: Rolling Snaphost, Disaster Recovery, Continuous Replication, Full Backup and Delta Backup.

Unfortunately, due to the way the snapshot process is implemented in XCP-ng, ignored VDIs will still be snapshotted before being deleted, which takes time and space unnecessarily, but we have discussed with the XCP-ng team and they are working on improving this

In the meantime, XO tries to work around this by temporary detaching these VDIs from the VM during the snapshot, but this only work when the VM is halted (see offline backup in the advanced settings of a backup job).

Ironically enough in my case, the VM I have that has a passthrough disk attached to it (a VDI I would like to [NOBAK]) is the VM that is setup as the remote for the backup job in XOA. So shutting it down wouldn't exactly work .

That being said I'm sure I could implement a workaround, but is there a feature request or tracking ticket URL somewhere where I can track XCP-ng team's work on this issue?

Thanks, @olivierlambert . It looks like the restore mostly worked. There was one main issue:

After I restored the configuration, all of the plugins I had had to manually configure when I first installed XOA (auth-ldap, transport-email, and usage-report) were all disabled. When I tried to re-enable them, they failed with the "plugin not configured" error. However, when I expanded their configuration, it was still present thanks to the restore. What I had to do was manually change an arbitrary field in each plugin so that I could click the "Save Configuration" button. Then I was able to re-enable the plugin. Probably a bug I should report?

Hello,

I'm working on a provisioning template to rebuild my XOA server without any sort of user interaction. A few questions:

1. Assume XOA and all plugins are installed. When restoring from backup, is it ONLY necessary to restore the "XO config" in order to bring XOA back into service 100%?
2. If not, what else needs to be backed up and restored?
3. Using the xo-cli to restore the config from backup, may I presume the following command is correct and the data.json file is the config file I want to restore?

xo-cli xo.importConfig @=/tmp/config_backup/xo-config-backups/2f26913f-81a5-4fbd-af86-ce83f90e525b/20220331T070000Z/data.json

Just to be clear, I'm not talking about restoring any XCP-NG hosts. I'm specifically talking about restoring XOA on a new VM.

@olivierlambert Thanks!

@nraynaud Thanks for working on this. Is the fix pushed to the latest stream or still in QA?