@olivierlambert for now we will go with Nakivo as we allready have a good experience with them, i will explore te agent based backups there to see if they can help to improve the backups of these vms. thanks again for the prompt response!

IIRC, everything is compressed using Brotli by default, including the full.

I have, what is hopefully a final update to this issue(s).

we upgraded to xoa version .99 a few weeks ago and the problem has now gone away. we suspect that some changes were made for timeouts in xoa that have resolved this , and a few other related problems.

@Andrew

Got it. As we only have a single production server there is no shared storage so I guess the idea of a pool is mute.

@olivierlambert Thanks! Seems obvious now that I clicked on it but I didn't know I could get to them through there.

Ping @florent

@olivierlambert If the issue turns up again.... It was a weird one!
As I deleted the previous backup jobs I can't repeat. Just had to move on.

Perhaps someone else stumbles upon this and finds this thread......

I will report if it happens again (will try it wit the new backup)

@McHenry Look at this post: VM limits - CPU Limits

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

@Bastien-Nollet

Thank you.

@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