A good specification is always better to do things correctly (and to estimate the work needed)

Usually this error is caused by the merge process still running in the background from a previous backup job.

@Danp Hi! Yes, this is working, but there seems to be no alert or "delete-schedule" for those backups

@lawrencesystems Excellent, that's what I was hoping to confirm.

If a schedule parameter to ignore NOBAK is fine since you can create an extra schedule in the same job, that should be doable. What do you think @florent ?

Hi, You can't tell XCP-ng to push a VM disk to a backup repository, it doesn't work that way.

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.