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

@KPS Perhaps consider AppV. MSIX. or some third party application sharing option for a chunk of the applications, which would reduce the size of the VM images? Also, perhaps the log verbosity could be reduced?

Are these issues resolved with a Full backup? Just curious as to how they might come about, and what the implications are. Thanks again

@Danp Thanks for confirming, not the end of the world, just happened to notice it.

@robyt Can you post a screenshot of where you see NBD? I don't see it anywhere in mine but I'm not sure if I'm looking at the right place. I think you need to get things working first and then start trying to push the envelop. I would set it to 1 and see what your speeds look like. Then you can slowly increase the number of connections until you stop seeing speed increases and/or you see http connection timeouts. I'll admit that I haven't been paying attention to the whole thread, but I'm not sure what more testing you feel you need in order to determine that the problem is your NAS. What is the goal you're attempting to achieve that you're concerned that different hardware wouldn't solve? I'm not sure what your configuration is (if you've posted it already, my apologies), but posting your XCP-ng host(s) details, XO specs, QNAP specs, and what other duties, if any, the QNAP is performing, that would be helpful. They make some powerful models, but most of them don't have that much oomph and can really only do one, maybe two things at once. And this goes doubly so if you're using very large VM disks instead of network storage. In my case I'm backing up to a fairly beefy TrueNAS running a 11z3 setup on a 10G network. My VMs are all configured with smallish disks and pull the majority of their data from the same NAS. My biggest bottleneck is that my XCP-ng hosts only have 2.5G NICs which is why I'm considering moving XO to something with 10G in order to support the fully bandwidth.

I may be able to help out here a bit, I've done a lot of testing and production backups to B2. Naming wise, Olivier is right, B2 is "S3 Compatible" which is why it works but it's not "officially" supported in that way. However since the S3 compatibility "layer" in B2 has been super solid, backing up to it using S3 protocol should be fine. As for your question about differentials, whatever backup jobs you setup are what will be put in B2. So if you setup full backups and select B2 as the remote for it, then it's full backups, etc.... I would recommend having your B2 backups be a different job than any local backups though (if you're doing local for faster restore), it's nice having control separately.