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.

Ping @florent

Yes, when you delete a snap, it must be coalesced. So everything is normal here. Switching the thread a solved, thanks for your feedback!

@rtjdamen said in Vinchin: i run into some issues related to specific vms, most likely caused by storage issues from the host or by the backup itself. We will give that some time to experience, in the meantime i want to understand the alternatives as well. No problem From a high level view, it appears that there is at least some integration of the product to support XCP-ng, likely either through an agent or API call. It's not a single pane of glass to view at the environment though, which might be irritating. As for the product itself I can't say as I've never used it.

@olivierlambert Haven't checked the CPU as CPU is never a problem on my load But yes this speed is a lot better so I can backup more frequently (every 2hrs for the important VM's) Actually the speed on my homelab is faster than the ones we get at the enterprise with "real" hardware.

We are using XOA, i have tried restarting XOA but that does not resolve the issue. You get a red exclamation mark direct when u select the virtual disk, then u reclick the disk and u get a list of partitions but it does not show the content. Maybe this first step is allready causing the issue? Robin

a case for this: have a lot old, disabled vms with some archive data\projects. Probably they will never be used again, but who knows. So i create 1 full backup, but when yet one vm go to archive, i need to run that task for all vms.

@michmoor0725 said in Only one back up wont restore: @manilx Thank you for the link. The fix in that thread worked. tldr. Problem with the ronivay self compiled code. Reverting to old commits fixed issue. Will be watching for a fix. This is a known issue that is in-progress, the issue isn't with the installation script you chose, but with XO Source specifically. Error: self-signed certificate This is something like the 15 topic here on the forums.

@florent said in Mirror backup with Continuous Replication: Backup from Storage Repository 2 to Backup Repository (Remote) We are looking at a similar setup. We currently do continuous replication from one host to another host and then want to take a weekly backup off from SR2 effectively to a NAS. Looking at one of these jobs, there is 31 days retention, and a fullbackup every 20 days. Is there a way I can match only the latest backup automatically so I can off-site just that to the NAS, and it come out as a full-backup, as I don't need to take 31 days worth, just the latest. I could adjust the full-backup interval perhaps to help with this and just take the most recent full backup although I don't think there is a tag for those? SR2 on the second host also has live VM's running on it as well as being a CR target. Or is there another way I can achieve this? I could take a backup directly from the running VM/SR1 direct to the NAS but I think that would interfere with the CR snapshot chain? Thanks, John

@Danp Yes, I am using the old one. I think I can overcome this by passing path and updating xo. Thank you. But I was able to get the job done by exporting the VHD file. xe vdi-list xe vdi-export uuid=33a94644-ef92-4ebe-8aef-77525c5931d9 filename=filename.vhd format=vhd OR curl -u 'root:pass' -X GET "192.168.1.100/export_raw_vdi?vdi=33a94644-ef92-4ebe-8aef-77525c5931d9&format=vhd" -o filename.vhd

Hi KPS, I think you have a couple of ways to tackle this -- You could adjust your current API jobs to exclude VMs with the restored from backup tag You could try using webhooks to clear the tags upon restoration of a VM. HTH, Dan

i done some tests. on same storage ofcourse. Transfer: delta 1st full - 5.98 GiB (1min) full no compression - 5.05 GiB (4min) full zstd compression - 1.84 GiB (3min) Indead looks weird. Time at least. Im dunno if snapshot counts at that numbers, but it store on host storage anyway. As for about space on storage itself, it can depend on thin\think, storage compression\dedup, block size, data blocks backup.

So, after a night of memtest and a few hours of cpu stress test, no crash or error with the RAM modules. In the meantime, I moved my XO VM to a different host (outside of the pool I'm backing up) and now everything seems OK, no more crashes. I still don't have any explication for the host crash, but at least I got the backup working.

@Danp Appears to be fixed [image: 1710158557946-ff868ae5-b5db-4464-93d5-bffb8080b644-image.png] [image: 1710158557940-e8a54367-698a-4249-97c3-d2397f33890e-image.png]

Hrm, I've always just reattached to the backup repo so I could see everything. Must've been a misunderstanding on my part. That's what I meant. Even a fresh XO without any previous config could restore backup if you add the backup repository at the same path where you had your backups before Sure, it's even easier to restore XO metadata because you don't have to remember where are you backups, but still, worst case scenario (losing everything except the BR), it's possible to restore.