@msupport we use the AnywhereUSB for this reason. Haven't tested the performance with USB disks, but it works good for all our license keys.

@Andrew Got it. So the DR host may have fewer resources than the production host, which would work for a failure of one or two VMs but not for a total failure of the production host whereby all VMs need to run on the DR host. Is it only RAM that is a consideration between hosts? Meaning if my production host has 16 vCPUs and my DR host only has 8 vCPUs can I still set the VM to use 16 vCPUs and it will work on both hosts?

@CodeMercenary i have seen this as well, one of our backup repos was almost out of space, this decreased the backup speed, we thought of issues on the xoa side but it was just related to the repo itself…. So it is good to check both. The 1 gig part makes sense.

Excellent Happy to see our fix solved your problem and enhanced our compatibility with older XenServer version. Don't forget to upgrade, the path to get to XCP-ng is relatively straightforward

Is it PV, HVM or a PVHVM VM? Health Check can't work on HVM because there are no tools.

@cirosantos0 Indeed, our detection is wrong in this case, I will put this in our backlog, but don't expect it to be fixed soon. PRs are welcome though

An update, if anyone ever comes across this via search engine. Turns out it was my container's timezone. The image was set to pure UTC, no timezone, by default, so I believe when it was writing files to my network storage it introduced a discrepancy. My network share was recording the file metadata accurately to real-time, so I assume when it came time to do another backup, the file time XO expected was different, making it think it was "stale" or still being "held". Have now run both scheduled metadata and VM backups without any errors . In summary: make sure your time, date and timezone are set correctly!

@julien-f , vm not found , no xapi associated to How we could be assure than everything is correctly backup ? Just received the XOA news with experimental VEEAM support , we will try these , we need something robust with advanced feature ( object storage , immutable , backup validation , dedup ) , with all encryption/ransom we need solid and functionnal DR plan with fast recovery and we are also checking HyperV

@florent It was working before, this is likely something that has been broken when the handling of snapshots has been moved from VMs to VDIs. We need to fix this.

@probain Noted in backlog

Hi, That's because our doc isn't fully up to date with the new naming (even XO in the app itself). See this recap: [image: Schema-new-wording-backup-2.png] More details in here: https://xen-orchestra.com/blog/xen-orchestra-5-83/#backup-nomenclature

I don't think it's a good approach, BR weren't meant for that. If you want to send them offsite, mirror backup is the best option. About immutability, we have an external program doing it if you want.

@stephane-m-dev understood. My suggestion regarding the different behavior (does not work with disk share, does work with user share) on unraid would be to put this in a "tip" in the documentation section about setting up Remotes.

I re-checked again but the issue is unfortunately not resolved. It does not happen on all VMs and files, so maybe there is something wrong somehow in the VDI?

@McHenry Base copies are not copy per say but a base of a VDI chain. [image: beforemerge.png] Here you can see that A and B are base copies for the snapshots C and E while D is the active VDI. You can find more info on this page: https://docs.xcp-ng.org/storage/#-coalesce

that a make a sense, now. So no issue here.

@daniel-grimm definitely not related to cloud in my case!

@DavidMrLane said in Where to find the health-check results: The tasks log doesn't tell you which VM was health checked. If you click the Open raw log button, it will give you the details on the request, including the UUID of the VM being tested -- { "id": "0m2dmjnnh", "properties": { "name": "VM Backup Health Check", "objectId": "remote-2//xo-vm-backups/92832a7e-e72d-2d02-6a25-9802f1c24072/20241017T050741Z.json", "userId": "3b480e98-af4e-4dbf-9f1e-29ac59d6364f", "type": "backup.vm.healthCheck" }, "start": 1729189103741, "status": "success", "updatedAt": 1729189318550, "end": 1729189318550 } In this case, the VM's UUID is 92832a7e-e72d-2d02-6a25-9802f1c24072, and you can paste this value into the filter when viewing the VM list in XO to find the exact VM involved.