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

Thank you for your report!

@mdavico said in Detached Backup Cleanup: @DustinB I understand that it does not appear there because the original VM does not exist. The reason could be that when recovering the VM before an emergency the UUID changed and these backups were left behind, I believe that there would be no reason to leave them there if you have new backups of the VM that is being executed or except for some other punctual reason. that your organization needs. Greetings Thanks, that's what I'm thinking as well, I'd love to compare UUID's to validate that. Just don't know if there is a relatively easy means of doing that.

@florent OK good to know, thank you! I will do what I can to replicate this issue in my lab and then see if changing to block backups fixes it, just want to try and avoid changing things too much in the prod environment. Appreciate the help!

You really need an application aware backup with AD. Option 1: Additional backup-software Option 2: Combine Windows-Backup with XOA --> A system-state-backup should be sufficient. Option 3: Install a new DC

That's the point, yes

@olivierlambert whoops! Well spotted Will post in the real one

The easiest solution is to change the destination CR for the replication, so it will start from scratch. I'm not sure you'll be able to move the whole chain like this (or maybe somehow manually but it will be tedious). I would go personally for a new SR target and start clean there.

@olivierlambert No problem at all, it was my pleasure. I hope it helps other having the issue.

@olivierlambert @florent thank you for the suggestions. So far I have attempted to do the following: Remote backup to NFS Remote backup to NFS target which is connected to another storage server using iSCSI Move the VM from one SR to another (on a completely different pool) Copy the VM to another pool Unfortunately, my VM size is not reducing. @florent said in Backup size larger than it should be: thin mode doesn't allocate space that is not needed. But once allocated, they stays there. This looks like an answer to me. In the worst-case scenario, I will have to recreate the VM and copy the data onto it