Why you wouldn't be able to deploy another XOA? It's meant to be re-deployed anytime you lose it, because even a fresh one can access a backup repo and restore everything.

@ph7 I am using an Incremental Replication backup (aka Continuous Replication) and I understand this is the same as Delta however Delta uses remotes whereas I.R. uses host storage.

That's indeed a solution. We could also maybe "revert" the condition for people with like 500 VMs to healthcheck except one.

@julien-f Tried again with today's release Xen Orchestra, commit 3d054 Master, commit 3d054 Same error again https://paste.vates.tech/?4941198dd850ed6d#ArUk6wqkwE2c3CQRbjwAXRERJd2Y4HWF5oq9ysMdkbBp Mirror incremental backup is broken here

XOA trial is enough to test it. Just ask another trial.

@florent Did you find anything? I just retested the job on latest XO build and have the same error.

I understand your requirements, I'm trying to pinpoint the issue. For now, everything converge on dom0 load when having many zstd processes at once.

@olivierlambert thanks, just to be sure.

@Nephilim Nothing shown here would indicate a problem AFAICS. P.S. Added proper markup to your post

Thanks @olivierlambert!

I don't know if it's still what he does

@McHenry Looks like you want disaster recovery option. It creates a ready-to-use VM on a separate XCP-ng server. If your main server fails you can start the vm directly off the second server. In any case, backups can be restored with XO to any server and storage available in XCP-ng.

Yes.

@Danp I don't really need something complex. I see the full & delta vhd files in each VM's folder but trying to mount the delta vhd with guestmount throws an error. There has to be a way to fold the delta vhds into the main vhd for the most up to date vhd..

@olivierlambert said in XO (from source): backup error (to Wasabi): If you need another trial, no problem. To me, the problem is not in XOA (the broken commit was done after the monthly release) and fixed today, so it means it would be never shipped in XOA. Then I am fine, building XO from Sources provides me with the ability to backup my VMs, which was the only XOA "Feature" I was using... Thanks anyway!!!

@olivierlambert It is now working thanks so much! Also wanted to share I really like XCP-NG!

@olivierlambert @Danp Hi, The backup task is OK and the replication backup is OK. I XCP-ng and XOCE. Thanks

@CJ Currently I do not see any bottleneck with disk and network IOPS as far as XOA and the remote destination are concerned. I'll look into a network share for the VMs if I notice that is becoming a bottleneck.

@Danp yup this was clearly due to lack of my experience reading the logs but after checking the path in the log and seeing I had no permissions I was able to understand it was related to the folder in the NFS share not allowing this host to make changes, strangely enough my other devices worked, but once I set up a new share it resolve the issue. Thanks for your reply.

There's many ways: no backup whatsoever. You will be able to restore your previous backups with a fresh XOA anyway (but you'll have to recreate the backup jobs and local users) metadata backup: very fast to backup and restore on a fresh XOA, probably the easiest way. With XOA, you also have Cloud enabled backup where you metadata will be saved directly on your Vates account (with a password and encrypted) "regular" backup on your XOA (full, incremental, replication…)