@olivierlambert whoops! Well spotted Will post in the real one

@florent you guys are absolute geniuses, there isn't a company in the world that matches your quality support.

I have a question though, say I have my backup set with 2 retentions on delta, and we do a full backup say each 20 backups. Am I right to assume that when the full backup occurs (so after 20 backups), in theory, there will be 2 full sets on the backup storage?

Example

Day 19:
Full.vhd
delta.vhd

On day 20:
oldfull.vhd (which is a merge of the day 19 full + delta)
newfull.vhd (which is the new VM)

Day 21:
full.vhd (which is now the old newfull.vhd)
delta.vhd (delta for day 21)

If so, that means that if we have large VM's (some are 2.5TB in size), there will come a time that that VM will use up double it's size on the backup storage.

Lastly, as we will be moving to XCP Pro + support in January, we want to move our backups from the now historical / community edition to the new one. I know at some point I saw you had moved to NBD backups and there is also an option to "test" the backups. Would this then make periodical full backups irrelevant as there would be no need to worry about backup corruption over time?

@florent Good morning @florent

I once again have to thank you guys for your amazing support (even in a case like this). I have added the 2 remotes to our paid enterprise version (it's added verbatim as per our community version).

Other info:

• Backups are setup as incremental
• Backups run either daily or weekly (2 backup jobs) but both configured the same
• 1 concurrent backup
• 2 Backup retention

I will open a ticket now, thank you!

@andrewperry yes, we replicate TrueNAS to a "standby" TrueNAS using zpool / truenas replication. Our current policy is hourly. We then (plan) to do Incremental replication of all VM's to a standby TrueNAS over weekends giving a 3 possible methods for recovery.

Currently we're running into a major drawback with VM's on TrueNAS over NFS (specifically VM's that rely on fast storage such as databases and recordings). We did not anticipate such a huge drop in performance having VHD files over NFS. We're reaching out to XCP to ask them to give us some advice as it could likely be in part due to customization we can make.

@andrewperry I think healthchecks is the answer here. We're not backing up vms but rather incremental replication with health checks. If a vm does not fail health checks I cannot see a reason for a full backup unless it becomes a snapshot chain issue. Olivier might be able to provide better insights here, we're in process of implementing the above will keep you posted

@nikade we'll be doing it right away, and given that I now know that there is potential challenges I can address with performance I'd rather give it a go. Thank you all for your feedback so far, a huge relief!

We will test this today and let you know. Ultimately the use case here is to be able to make use of a failover NAS (which is replicated at NAS level) so that it's a simpler process to switch to a failover in the event of failure (else there is no practical point to replicate the VHD's between external storage servers if we cannot "switch" to another NAS.

I will let you know the outcome, but agree with @Forza that if this does work it would be a great addition to the GUI to allow for a "switch to failover" scenario

You guys are absolute rockstarts! Yannick connected and was able to resolve the issue, thank you again for all of your hard work!

@olivierlambert strange one, thank you Olivier, I created a ticket 7714072

Thank you all seems I've got my answer, will go core

@olivierlambert you're a grandmaster, never even considered that It seems to be stuck but likely firewall will have a look thank you

Just checking if there is any impact in XCP-NG and / or XO that may be impacted by the log4j vulerability? Not sure if some of the API's uses java?

@olivierlambert Perfect, setting the parameter on both the VM and the snapshot resolves the issue. I am able to continue backups Thank you both for helping!