Since 2020, we added pool metadata restore for exactly this It should be really straightforward. The best way to validate it, is to use an experimental host, backup metadata, then reinstall a fresh XCP-ng from scratch on top of it, and then restore the metadata. That should work out of the box

@archw Scratch that one.....I should have googled first. I saw that someone suggested deleting the cache.json.gz file. I did and ran it again and it worked.

@olivierlambert that does look interesting. I really need to find a way to make it work over scp/sftp unless you have an in with rsync.net and can get them to add an S3-compatible service It's not really practical to make a move to an S3 provider at this time; we are 230 TB into rsync.net for a damn good price with no extra charges for data ingress or egress. If I add VM backup, the additional 10+ terabytes are a drop in the bucket of the overall usage.

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