@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!

Any ideas on how I can clean up these logs?

The other perk is reduced CPU usage in your Dom0 too Well, it works pretty good and I don't see a reason to not use it.

@CJ Gotcha, I see, yeah either way I think having more control over backups would be useful, never really a downside to that haha.

@Danp From what @florent stated in the other thread, it should be fixed, but I'm having it happen on every backup so he's looking into it again.

@mdavico You may be able to change the directory path on your remote storage so that it matches the new UUID, but this isn't something that I can verify at the moment. If you have already performed the full backup on the new backup job, then I would expect the future backups to be deltas.

Looking through things, I think I've determined part of the reason for the larger backups. When I turned on memory snapshots that means that the memory is now getting saved as a separate VHD and then transferred. Is it possible for the backup job status to provide more information regarding memory vs actual disk parts of the snapshots? For example, the cleanup task now shows two unused VHD, which I assume is the separate memory and disk VHD for the snapshot.

@olivierlambert Thank you for the quick reply! I am looking forward to the changes!

@julien-f that fixed it, thanks very much for the prompt resolution!

You should be able to delete the snapshots without causing any harm. A couple of things to keep in mind -- If the snapshot is associated with an existing backup job, then the next run of that job will result in a full backup instead of a delta It may take some time for the snapshots to coalesce following deletion, so this could still affect your backups until they are completely removed If you want to delete the backups associated with the old job, then you can from the Backup > Health tab in XO

@julien-f Thank you! That appears to fix the error. Greatly appreciate your help and @olivierlambert.

@archw said in Backup fails with "all targets have failed, step: writer.beforeBackup()": @florent Where would I find that log? I assume its in /var/log but which file? For a xoa it's in journalctl -u xo-server from source, it depends how you did setup XO

Thanks for the feedback. I'll take a look at it.

@florent I see it has been merged into master. Yes, transfer size seems to be back to before. I have not checked for damage. At worst I can just force a full backup.

It seems like you are confusing xcp-ng (the virtualization server) with XO (the VM for managing xcp-ng). Based on your earlier post, you needed to update XO, not xcp-ng. Therefore, you should be able to rerun your XenOrchestraInstallerUpdater script to update XO to the latest source commits.