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

If you want to work with the backup features, but aren't using this in production, then you can compile XO from the sources and deploy it that way, then use the backup features. If this is for production though, would def recommend getting support (so purchasing XOA) in case something goes wrong.

OK, I found where to put the email address in the backup-report plugin. It is just odd in the UI that for VM Backup & Replication and VM Mirror backup you can specify an email address for each job, but not for XO Pool & Metadata backup type. Thanks for the help,

@florent It looks like things are working as expected now. If there are changes that need to be backed up the vms run a health check now. If there are no changes no health check is ran. Thank you!

@florent I've been away for a few days so sorry for not replying sooner. Thank you all for your advice. I have still been unable to set up encryption on an s3 remote. I even tried a different provider (iDrive e2) but got the same error. I did manage to do it with backblaze b2 but the download speed for restore was too slow. I take onboard planedrop's point about https encrypting data in flight so if I proceed in production I will use the encryption tools provided by the s3 provider and ensure I always use https. Having said that I will probably wait till the s3 remote is no longer in beta. Once again thanks everyone.

Have you selected backupNg.runJob? Only then you can select "post".

@DustyArmstrong Got it got it! Makes total sense. I do think making sure you somehow are backing things up in a way that covers large natural disasters is important, not quite sure what the ideal solution here would be though.