@Danp No, I am not familiar with many of the "manual" commands. I have to figure out how to use that with LVM over iSCSI. Meanwhile, I stopped the VM, did a SR scan and it coalesced successfully. Offline always works fine....

Yes, XO handles compression and decompression automatically. Glad to know it worked for you!

@olivierlambert No, CRON patterns does not support this kind of scheduling.

@olivierlambert Sorry I didn't make this clear. I have multiple servers and one of them will not be used for production VMs. That's the server that happens to have a large amount of storage. I would not store backups on the same hardware as production work and this will not be my only backup of the production data. This server just has more storage than I have a use for so I thought it would be nice to use it for storing backups for the production servers since backups with history need a lot of space. I do have an older server that I was considering using for backups but it just doesn't have nearly the storage as the one I'm talking about. 8TB as opposed to 90TB and it can't be easily expanded storage-wise. That one would be easier to convert to TrueNAS on bare metal. It occurred to me last night that I could create 2TB drives for the XO VM on that server and backup to local storage in the VM. Actually one of my instances of XO is running on bare metal, instead of a VM, on that 8TB server so I could use that to backup to local storage if I didn't want to go with TrueNAS but TrueNAS has some other advantages, like providing an ISO share separate from my XCP-ng servers so it likely makes sense to go that route.

Hi, That's normal as your trial ends. I can extend it if you need

@florent Thanks. OK, so for one time remote migration I will be fine with multiple rsync runs plus switching the central remote for my backups. Nice to have both options though.

@Danp There were no entries regarding backup listed by the journalctl command for the target backup time. I've updated my XO to commit 16498, and restarted the XO VM. The backup ran ok Today. Thank you @DustinB and @Danp for responding to my post! Alex

@Delgado said in Health Checks Failing: @florent can confirm that health checks are working again! Thanks for the prompt reply! thanks for the precise bug report, that is half of the job done

@florent I updated to build 16498 and followed your suggestion. Now it is showing that the connection is running and successful. I have a 2-day object lock enabled. In BackBlaze B2 Buckets once object lock is enabled you cannot disable it. You can change the days to lock to 0 but that will only affect new files. Existing files will be locked based on the Object lock settings applied when the file was saved. It appears that this is resolved. I will try to run a few backups to my BackBlaze buckets to see if it runs.

Ghost XO user authentication task has nothing to do with backup restore, it is a known bug that will likely be fixed in the next release.

Roughly, a snapshot is created and transferred while all new blocks written are mirrored to the destination. When the entire snapshot is created on destination, the VM is frozen few ms to finish consolidating the mirrored blocks into the destination snapshot. And then the memory is transferred.

@olivierlambert I think that was probably related to my question if he tried to connect the same NFS share on the Synology as storage and backup target

@florent Thank you for the update.

Snapshot will stay until the next backup. It's the "point of reference". But it shouldn't stay attached ot the Dom0 after it's done.

Yes, that would be better to open a ticket at that point

@lawrencesystems Thank you for the reply! I considered BHC in the past, wasn't sure to how big to make the SR for the restores BTW Love your XCP YT content, helped me understand so many features and best practices

Thank you for the update Andy.

You are welcome

There's no way we can do incremental since the VDI is changed/rebuilt during a migration (it's a new VDI created). As soon as you move a VDI, a new full is done automatically because the VHD is entirely new. Doing incremental on top of it would corrupt it.