Hi @McHenry If you still have the problem, you can increase the healthCheckTimeout value as Olivier recommended (e.g. healthCheckTimeout = ‘30m’), however this value should be in the [backups.defaultSettings] section of the configuration file (or in the [backups.vm.defaultSettings] section) rather than in the [backups] section. We've detailed the documentation a bit to make this more understandable: https://github.com/vatesfr/xen-orchestra/blob/a945888e63dd37227262eddc8a14850295fa303f/packages/xo-server/config.toml#L78-L79

Hi, I'm not sure to get it, pinging @julien-f

It's up to you to do whatever you need with the VM copy. Clone the replicated VM, remove the NICs (for example) and boot it.

@DustinB Drives from a secondary NAS

@DustinB Yes, I completely agree and understand everything you're saying. All of my compute is used elsewhere and I have no spares. In my situation where I lack the budget (and time) for something more robust, USB HDD manual backups will work perfectly well for me (atleast temporarily in these early stages) to preserve my investment of months of work on my datacenter. I appreciate your insights though.

@olivierlambert Great. Posted here and didn't open ticket because this is interesting for all ...

@Danp Ah, thank you for that. I need to restructure things a bit but I was already thinking I would do that. The issue is that this VM also runs NUT so it's the last VM running before shutting down the servers. I reduced the memory because it takes a LONG time to suspend a VM with 16GB RAM but doesn't take long to shut one down. Between the 8 to 10 minutes it takes for XCP-ng to shut down and the time it takes to suspend a VM with 16GB RAM, I don't think my batteries will last that long. I'll have to move NUT into a leaner VM that doesn't handle backups. That's something I was thinking I would do anyway because if there was a power outage during a backup I don't think my NUT script would be able to do what it needs to do. Based on the cron job I run to make sure my xo-cli registration is good, the xo-cli stuff won't run when the VM is hammered like this. Thanks for helping me understand why this happens and how to fix it.

Yes, the default timeout for XAPI tasks is 24 hours. This can be modified as explained in the documentation -- https://docs.xcp-ng.org/management/manage-locally/api/#24h-task-timeout

Your backup won't be affected if the VM is rebooted while the backup is running.

Ping @florent

Ping @florent

@flakpyro for now there is no tag selector , but you can now select the VM list to be replicated

Hi, For reference, it's in our "Product management" backlog on ref PRODU-69. Now we need to find the time to prioritize this and investigate on it first (how much effort needed).

@Prilly Looks like @lawrencesystems has a good explainer video on YouTube at https://youtu.be/weVoKm8kDb4?si=QH93rOKaXLglrIbS Check it out when you get a chance, thanks.

Found this... https://xcp-ng.org/forum/topic/3553/creating-schedules-to-run-on-specific-days

@CodeMercenary I use the paid for XOA and it backups up its config to the cloud so it wouldn't be a problem for me to restore. You can easily set something like that up by backing up to a store location then having that backup to a cloud storage location. As far as having the XO instances running Im not sure how that would work. I know with NBD storage you should be able to connect to the hard drive with multiple XO's (I think) but the problem I ran into quickly was the fact that when I made a backup using my XOA, the XO from source would see it as a backup without an associated job. If you had three XO's running with 3 different remote storage locations I don't think you'd have a problem with that. Instead you might run into the XO's seeing the 3 different backup jobs running , 2 of which, they don't know about. I use XOA to backup to a different storage array, then I have that storage backup to the cloud. My backups aren't really up to "standard" but thats all I can do for now. My plan is to make backups to a different storage pool on the same central storage I run my VM's on, back that whole unit up to an off site unit with ZFS replication, then back that backup to the cloud with StorJ. Right now Ive just got the one backup on the same Storage server and the StorJ.

@florent Finally getting back to this post, I know it's been months, just haven't had a lot of time, sorry! I think I am still a bit confused, but I will do some additional testing to see if I can confirm my suspicions. My confusion is that, you can't merge the deltas into the key if the key is locked behind Object Lock, the file isn't writable so you can't do the merge operation, right? So that being said, it sounds to me like maybe the retention of the object lock/immutability needs to be set to be less than the retention period in XOA, right? This way the original key is not immutable and can be written to when the merge happens? Or does XOA just "wait" until the key isn't locked and then do the merge operation?

@florent Looking forward to the docs. Just this one thing (Guess most would be interested): On my example: keeping 7 daily backups, I presume it keeps the last backup from each day (as there are 2 schedules I presume it would keep the backup from 22:00)