@olivierlambert Sure It was just a question I know WE don't have same infra or feature IS not vmware but thé stack IS really good and interesting And i Saw Comvault IS compatible with your stack and WE will replace networker with Comvault during next year

@planedrop I usually don't use SMB for remotes - prefer for stability reasons NFS. But in the past on customer systems we had, from time to time, the problem that the SMB Client/Server (both had the problem, so it might be the case that they stalled each other) processes stalled for a moment, which might cause that file locks are not set or ended correctly. Maybe it's something like this in your case too. Catching that is a bit of a pain in the *** , because you need to do process memory tracking on both sides to see if and when they stall for a short moment. Not sure if there is a way under TrueNAS to check if a file has a lock set or not. If possible it might be already enough to remove the lock of the file (if possible via cli) to make it visible to the XCP-NG host again.

Yeah it sounds that the merge on the backup side can't succeed since the chain seems corrupted.

@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