If you want to work with the backup features, but aren't using this in production, then you can compile XO from the sources and deploy it that way, then use the backup features. If this is for production though, would def recommend getting support (so purchasing XOA) in case something goes wrong.

OK, I found where to put the email address in the backup-report plugin. It is just odd in the UI that for VM Backup & Replication and VM Mirror backup you can specify an email address for each job, but not for XO Pool & Metadata backup type. Thanks for the help,

@florent It looks like things are working as expected now. If there are changes that need to be backed up the vms run a health check now. If there are no changes no health check is ran. Thank you!

@florent I've been away for a few days so sorry for not replying sooner. Thank you all for your advice. I have still been unable to set up encryption on an s3 remote. I even tried a different provider (iDrive e2) but got the same error. I did manage to do it with backblaze b2 but the download speed for restore was too slow. I take onboard planedrop's point about https encrypting data in flight so if I proceed in production I will use the encryption tools provided by the s3 provider and ensure I always use https. Having said that I will probably wait till the s3 remote is no longer in beta. Once again thanks everyone.

Have you selected backupNg.runJob? Only then you can select "post".

@DustyArmstrong Got it got it! Makes total sense. I do think making sure you somehow are backing things up in a way that covers large natural disasters is important, not quite sure what the ideal solution here would be though.

@rmaclachlan said in Is it possible yet to select a specific network adapter for Backups?: On the Pool > Advanced tab you can select a backup network so if you created a backup network for a specific NIC you could set it there [image: 1708097136464-6e1a7467-a12b-4017-b61a-98f1051ab925-image.png] Oh I saw that too, I was uncertain of the wording, does "Backup network" actually mean the network adapters to use to backup VMs or is it a backup incase something breaks?

@KPS Perhaps consider AppV. MSIX. or some third party application sharing option for a chunk of the applications, which would reduce the size of the VM images? Also, perhaps the log verbosity could be reduced?

Are these issues resolved with a Full backup? Just curious as to how they might come about, and what the implications are. Thanks again

@Danp Thanks for confirming, not the end of the world, just happened to notice it.

@robyt Can you post a screenshot of where you see NBD? I don't see it anywhere in mine but I'm not sure if I'm looking at the right place. I think you need to get things working first and then start trying to push the envelop. I would set it to 1 and see what your speeds look like. Then you can slowly increase the number of connections until you stop seeing speed increases and/or you see http connection timeouts. I'll admit that I haven't been paying attention to the whole thread, but I'm not sure what more testing you feel you need in order to determine that the problem is your NAS. What is the goal you're attempting to achieve that you're concerned that different hardware wouldn't solve? I'm not sure what your configuration is (if you've posted it already, my apologies), but posting your XCP-ng host(s) details, XO specs, QNAP specs, and what other duties, if any, the QNAP is performing, that would be helpful. They make some powerful models, but most of them don't have that much oomph and can really only do one, maybe two things at once. And this goes doubly so if you're using very large VM disks instead of network storage. In my case I'm backing up to a fairly beefy TrueNAS running a 11z3 setup on a 10G network. My VMs are all configured with smallish disks and pull the majority of their data from the same NAS. My biggest bottleneck is that my XCP-ng hosts only have 2.5G NICs which is why I'm considering moving XO to something with 10G in order to support the fully bandwidth.

I may be able to help out here a bit, I've done a lot of testing and production backups to B2. Naming wise, Olivier is right, B2 is "S3 Compatible" which is why it works but it's not "officially" supported in that way. However since the S3 compatibility "layer" in B2 has been super solid, backing up to it using S3 protocol should be fine. As for your question about differentials, whatever backup jobs you setup are what will be put in B2. So if you setup full backups and select B2 as the remote for it, then it's full backups, etc.... I would recommend having your B2 backups be a different job than any local backups though (if you're doing local for faster restore), it's nice having control separately.

@DustinB Seems like just attaching the remote SR found all the backups. Now to test if they work One of the restores worked so that's good. Attempting a full backup now to see if updating to newest version fixed all our issues. We also had some VDI chain issues when running backups, so seems like VDI's are refusing to coalesce for some reason. Will report back after testing.

@olivierlambert Thank you for the confirmation.

@lawrencesystems Maybe get behind and help with code and/or sponsorship of this feature request. https://xcp-ng.org/forum/topic/8252/tag-based-selection-for-multiple-vdi-storages/8 Cause this is a part required for what you are looking for as it will increase tag functionality. Specifically enabling tags to specify the affinity for where VDIs are stored (which SR they go to). There's already this feature present for VMs to ensure that they go to the correct hosts.

@florent I'm not sure what's going on, but the incorrect size warning seems to be intermittent now. Jan 22nd - No size warning. Half of the VMs cleaned 1 unused VHD, the others had 0. Jan 23rd - Size warning and 1 unused VHD cleaned on half of the VMs. Others had neither. Jan 24th - Same as Jan 23rd. Jan 25th - Size warning and 2 unused VHD cleaned on half of the VMs. Others had 1 unused VHD cleaned. Jan 26th - No size warning. All VMs cleaned 1 unused VHD. It doesn't seem host related as each host had VMs in both categories. Hope this helps. Let me know if you need any more info.

@olivierlambert said in In delta backup force the full backup task in a specific day: Block mode with NBD enabled? That sounds too slow, especially for a first backup (which will be full and won't require any merge) [image: 1706278573918-0e57de89-11e1-4a42-a34c-162d4151f754-immagine.png] is locked to 37%... ho i can stop the backup job without damage old backups?

@julien-f Awesome. I was mostly concerned that I was tagging the VM incorrectly as I didn't want it to backup. I'm happy to report that the tag worked correctly.

That's right: what you need is in the backup section, not jobs Happy to help, have a nice day too!